RE: Issue-207

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

However dynamic or static the TSR is, the mechanism can obviously be used to qualify the D as Jack suggested, and as we described in our text. It could only lead to large scale cache invalidations if it became a widespread response, which was not how it was envisaged.

If we imagine many servers are going to use the D response, I think  Jonathan's idea was best (rule it out of court) because otherwise the standard will be pointless.

mike

> -----Original Message-----
> From: David Singer [mailto:singer@apple.com]
> Sent: 09 May 2014 21:01
> To: Jack L. Hobaugh Jr
> Cc: Roy T. Fielding; W3C DNT Working Group Mailing List
> Subject: Re: Issue-207
> 
> Hi
> 
> I think it’s as dynamic as the site wants it to be.  Just as some sites tailor their
> ‘normal’ content based on various information in the request headers (“if you
> visit my site from an IP address in the UK, I show you different content than
> others”, and indeed varying the served content by user-agent used to be quite
> common to work around which UAs had implemented, or had bugs in, various
> features), the TSR can appear ‘static’ but actually be subject to ‘internal’
> dynamism at the server.  I think.  I may be wrong (it’s friday, that’s my excuse).
> 
> 
> On May 9, 2014, at 12:24 , Jack L. Hobaugh Jr <jack@networkadvertising.org>
> wrote:
> 
> > Hi Roy,
> >
> > Thanks for your response.
> >
> > Perhaps I misunderstood your original statement.  I understood you to state
> that the TSR itself is dynamic.
> >
> > My understanding of Section 6 of the TPE is that the TSR is a static, but
> modifiable, JSON entity.
> >
> > If you view the TSR as a dynamic entity, an explanation would be helpful.
> >
> > Best regards,
> >
> > Jack
> >
> > Jack L. Hobaugh Jr
> > Network Advertising Initiative | Counsel
> > 1620 Eye St. NW, Suite 210 Washington, DC 20006
> > P: 202-347-5341 | jack@networkadvertising.org
> >
> > The information contained in this e-mail is confidential and intended for the
> named recipient(s) only. However, it is not intended as legal advice nor should
> you consider it as such. You should contact a lawyer for any legal advice. If you
> are not an intended recipient of this email you must not copy, distribute or take
> any further action in reliance on it and you should delete it and notify the sender
> immediately.
> >
> >
> >
> >
> >
> > On May 9, 2014, at 1:01 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> >
> >> On May 9, 2014, at 7:23 AM, Jack L. Hobaugh Jr wrote:
> >>
> >>> Hi Roy,
> >>>
> >>> Thanks for your response.
> >>>
> >>> Please further explain how the TSR would be used as a dynamic, per user
> response.
> >>>
> >>> My understanding of the TSR as specified in Section 6.4 of the TPE is that the
> TSR is a static JSON representation on the server that contains information
> about either the potential tracking behavior of resources on that server or can
> be used to represent multiple, request specific tracking polices (also static JSON
> format) on the server that can be identified by a status-id value returned in the
> Tk header.
> >>
> >> The response is like any other page on the Web.  It can be dynamically
> >> produced or static.  For any tracking site that indicates consent, it will
> >> have to be dynamic.  This is why the user agent needs to send its normal
> >> cookies for the designated site when making the request.
> >>
> >>> Also, my understanding is that the JSON representation will be updatable but
> normally static.  If that is true then isn’t it also true that the only possibility for a
> dynamic response would be through the choice (by the server) of appending a
> particular status-id to the Tk header based on information in the request?
> >>
> >> Please see the section on caching in TPE.
> >>
> >> ....Roy
> >>
> >
> 
> David Singer
> Manager, Software Standards, Apple Inc.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.2.42.4591 - http://www.gpg4o.de/
Charset: utf-8

iQEcBAEBAgAGBQJTbeODAAoJEHMxUy4uXm2JescH+gJG63XWkN5uGeKJO4mxsY7U
uiNxGKNUEgHdMV5acc+KqoGnkidUYFZDGfWyfn4iImKXMfvLsytRMxP1ZyDchg5I
6v/poBGyHLglD/vLF1W+2IkmXeRE5iCEjSPNkT4QdDq/d6G5ZYu6ad04+QnnOzNi
OiGnQWLI/wk3WwRK9rI+t9uS2IirnplveZ5CE0kLxKX+tebwu/mmFY91LxUPzcTE
q00jFIOtQ8LPwVMPUklaJ5w/CIv8FSyogWRlfpA0sX++b8IG7WNRz1lUQZICe9Z5
A/m/jah+8Tbg6bmPigxs2PUFj9tJoWqnzeZWfgfAmEKIndZi0KiXshdk3RlU6OE=
=anL9
-----END PGP SIGNATURE-----

Received on Saturday, 10 May 2014 08:30:32 UTC