W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 8 Oct 2009 13:44:52 +1100
Cc: "'Henrik Nordstrom'" <henrik@henriknordstrom.net>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <70215137-ACB2-4567-9CBF-5AF9FE3C6F72@mnot.net>
To: "Brian Smith" <brian@briansmith.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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:52 UTC