Re: Follow up from the meeting on Issue 14: timeouts

I'm OK with #1.

Eventually, I think we may want to edit 2.2.1 to include this. I have seen
quite a bit of variation in interpretation 2.2.1 over the years regarding
inactivity timeout so would welcome an opportunity to combine the two
tighten up the wording while not reducing 2.2.1 (as per our charter)

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Tue, May 9, 2017 at 1:53 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> Minor nit,
>
> Often, "timeouts" are not set "...by the content..." but rather enforced
> by the server as part of a larger security "blanket" of requirements and
> configuration settings. As such, I'd like to see an editorial change,
> perhaps along the lines of:
>
> "For each time limit set by the content encountered by the user where
> user-entered data can be lost..."
>
>
> John, I’m concerned that if it is time limits encountered by the user then
> we need to deal with time limits that are out of the control of the content
> provider (e.g. Ticket availability, editorial deadline for a form to submit
> a letter to the editor, etc.). Since 2.2.1 says "For each time limit that
> is set by the content” it seemed practical to use the same language here.
> If the author doesn’t have the ability to control the limits, we should
> just have an SC that requires 24 hour data retention since there would
> always be the possibility of a security blanket.
>
> AWK
>
>
>
>