- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 8 Oct 2009 13:44:52 +1100
- To: "Brian Smith" <brian@briansmith.org>
- Cc: "'Henrik Nordstrom'" <henrik@henriknordstrom.net>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
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. On 08/10/2009, at 1:36 PM, Brian Smith wrote: > Mark Nottingham wrote: >> 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). >> """ > > 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 > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 8 October 2009 02:45:29 UTC