- From: <bugzilla@wiggum.w3.org>
- Date: Sun, 18 Oct 2009 10:01:55 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7689
Ian 'Hixie' Hickson <ian@hixie.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |NEEDSINFO
--- Comment #7 from Ian 'Hixie' Hickson <ian@hixie.ch> 2009-10-18 10:01:55 ---
> The contradiction is that a description of what the algorithm does is in
> non-normative text.
Why is that a contradiction? Non-normative text often explains the implications
of normative text.
> > The bit you quoted at the very top of this bug is about user agents sending
> > cache-related headers _to_ the server, which is completely unrelated.
>
> My point is that the spec is inconsistent in its approach towards cache
> semantics.
Consistency is not necessarily a goal (though it's nice in general). In this
case, it seems the inconsistency, such as it is, is warranted by the different
and asymmetric needs of server-side and client-side requirements.
> > > My proposal is to either be specific in a normative manner about the kinds of
> > > cache semantics that must be ignored or may be permitted. The specific
> > > semantics that are actually applied are then bounded in this range.
> >
> > Do you have any suggestions for what should _not_ be permitted? I don't really
> > understand what this would look like.
>
> Cache defeating semantics are identified here -
> http://www.basswood.com/standards/WD-countmethod.html. Identifying the
> techniques that are permitted should be either good enough or leaving out the
> whole discussion on cache-defeating semantics should be fine. The current
> situation doesn't really help anyone.
That doesn't really answer my question.
There's no point listing which features are permitted if all of them are
permitted. Which should _not_ be permitted?
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 18 October 2009 10:01:57 UTC