- 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