Re: ACTION-254: Draft text on freq. capping that would avoid new definitions and/or remove redundant normative requirement

Hi Shane,

On Oct 31, 2012, at 5:11 AM, Shane Wiley <wileys@yahoo-inc.com> wrote:

> Nick,
> 
> Good points.
> 
> 1)  We should generally agree if we're going to repeat elements of the "master" Permitted Uses rules in the individual Permitted Uses.  I believe Rigo recently asked for a non-normative reminder for the "Finance/Audit" Permitted Use.  I personally think this is wasteful and bloats the document unnecessarily.  Others may think that implementers will only look at very specific sections of the document and not read the entire document so these types of re-statements will be necessary.

Agree we should be consistent; I'm fine either way.

> 2)  Fine with using different terms - or making a simple statement of "not retaining URL history" as any method that achieves that outcome meets the rule.

I think then that we may have pared this section down to a single key requirement:

>>> Operators may retain data related to a communication in a third-party context to use for limiting how often advertisements are shown to a particular user if the data retained do not include the user's browsing history (for example, page URIs on which ads were past delivered).

With non-normative examples provided as well. (Those are yet to be drafted; we should probably divide up action items there.)

> 3)  I like the idea of adding the client-side storage example here.  Why would we move this non-normative text (examples) to an appendix though?  Are we going to do that for all non-normative text?

Some have asked that we move some of the non-normative techniques sections to an appendix, and so I volunteered to draft what that would look like (action-325). I think it can provide a more readable document that way -- the main sections explain your requirements, an appendix tells you some handy ways you might accomplish those requirements, although of course you can use other means as well. (I'm certainly not wedded to this one way or another.)

Thanks,
Nick

Received on Wednesday, 7 November 2012 06:36:34 UTC