Subject: Re: #197: Effect of CC directives on history lists

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Oct 2009 11:37:44 +1100

Existing text:

>   By default, an expiration time does not apply to history  
> mechanisms. If the entity is still
>   in storage, a history mechanism SHOULD display it even if the  
> entity has expired,
>   unless the user has specifically configured the agent to refresh  
> expired history documents.
>
>   This is not to be construed to prohibit the history mechanism from  
> telling the user that a
>   view might be stale.

Proposed text:

"""
   By default, the freshness model [ref] does not apply to history  
mechanisms. If the entity is still
   in storage, a history mechanism SHOULD display it even if the  
entity has expired,
   unless the user has specifically configured the agent to refresh  
expired history documents.

   This is not to be construed to prohibit the history mechanism from  
telling the user that a
   view might be stale, or from honoring cache directives (e.g., Cache- 
Control: no-store).
"""

On 22/09/2009, at 4:49 AM, Henrik Nordstrom wrote:

> mån 2009-09-21 klockan 10:05 -0500 skrev Brian Smith:
>> Henrik Nordstrom wrote:
>>> But this part of the specifications should only be advisory and best
>>> practice recommendation, giving browsers permission to bypass  
>>> freshness
>>> controls on accesses due to history navigation, not a strict
>>> requirement on implementaitons to do exactly this.
>>
>> Why does the HTTP specification even need to mention history lists.
>> The vast majority of HTTP caches do not even maintain history lists.
>> The ones that do (built into browsers) will design their history list
>> mechanism according to their own security & performance goals. Plus,
>> as Henrik noted previously, there's a lot more to a browser history
>> list than caching the HTTP request/response (ActiveX/plugin state,
>> Javascript state, SVG animation state, Javascript APIs for  
>> controlling
>> history, etc.)
>
> It's an explicit freedom to disregard HTTP freshness controls in  
> history
> buffers and the like.
>
> But yes, the fine details there belongs more in a browser profile
> specification than the HTTP specifications as such.
>
> Regards
> Henrik
>

--
Mark Nottingham     http://www.mnot.net/

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 7 Oct 2009 21:36:17 -0500

Mark Nottingham wrote:
> mechanisms. If the entity is still in storage, a history
> mechanism SHOULD display it even if the entity has expired,
> telling the user that a view might be stale, or from honoring
> cache directives (e.g., Cache-Control: no-store).
> """

Why not just:

    A client MAY or MAY NOT use the freshness model [ref] when
    implementing a history mechanism.

Like I said before, it doesn't make sense to talk about client UI
in this specification, since client UI designers don't care what
this specification has to say about UI issues anyway. The less said,
the better.

Besides, "SHOULD display" doesn't make sense considering the client
might not have a display, and/or there are many reasons why it might 
feel it MUST/SHOULD NOT present an item besides the one particular
setting you mentioned (for example, private browsing settings,
anti-time-wasting utilities, etc.).

Regards,
Brian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Oct 2009 13:44:52 +1100

I think all of the text you're concerned about is motivated by the  
note underneath.

I can see reducing the SHOULD to be non-normative here, but I still  
think something about it needs to be said, so people won't  
misunderstand the statement that freshness doesn't apply.