View source for Obsolete vs Rescinded vs Superseded Recommendations Comment

===Comment====
  Let's take for instance documents like CSS2.0 
  (https://www.w3.org/TR/2008/REC-CSS2-20080411/), or CSS1 
  (https://www.w3.org/TR/CSS1/), setting aside for a minute 
  that fact that they predate the current process or the current 
  patent policy. These have been replaced by newer documents which 
  occasionally conflict with them, and no errata is being maintained 
  (CSS2.1 does have errata when newer specs conflict, and not all of 
  it has been replaced, so it's not relevant here).
  From a patent point of view, if the newer REC is a strict superset 
  of the old one, the old one no longer being covered by the patent 
  policy wouldn't be a problem, but if they have, as sometimes happens, 
  conflicting normative requirements, there could be cases of patents 
  having claims that cover one but not the other.
  Is the current practice of including prominent (albeit ad-hoc) 
  warning notes in such specifications sufficient? Should they be 
  rescinded? Should they be Obsoleted? Should we create another 
  "Superseded" status? Does the answer depend on whether the 
  document in question predates the patent policy?
  In short, my idea of a Superseded REC would be:
   - the patent policy continues to apply (if it ever did)
   - new implementations are discouraged, and SHOULD refer to the newer 
     document instead
   - new TR documents MUST NOT normatively refer to it (informative 
     references for historical purposes are OK)
   - The superseded REC MUST have (a) link(s) to the document(s) 
     that supersede it
   - The superseded REC SHOULD state whether the document that replaces 
     it is merely an extension, or whether they have conflicting normative 
     requirements (this is only a should, because making it a must might 
     get in the way of marking as superseded RECs that should be, when it 
     is not known whether there are conflicts, and nobody is stepping up to 
     do the work needed to find out).
  One key difference with Obsolete RECs is that the the only case I can 
  think of for a superseded REC to become a   normal REC again is if the 
  document that superseded it is itself rescinded due to patent claims

  '''Discussion'''
  '''DS:''' [the process for obsoleting] was intended to cover this case.  
  If that’s not clear, we should make it so. I would like to keep it simple and 
  allow Obsolete to include “superseded” (e.g. by a spec. of another name, 
  another body, or the like).
  '''FR:''' I agree that Superseded is effectively a subcase of Obsolete. 
  I think it could be useful to distinguish, but I don't think it is 
  strictly required
  '''DMN:''' TL;DR: What you are calling Superseded seems to be a strict 
  subset of what the process document is trying to do by introducing 
  "obsolete" IMHO. And IMHO, I don't think there is enough importance in 
  recognising different subsets to justify distinguishing them in the 
  process. But there are some gems in here too…
  Did you read Ian Jacobs' recent review comments [https://www.w3.org/community/w3process/wiki/Largely_Editorial_Comments_from_Ian_Jacobs#6.9_Obsoleting_or_Rescinding_a_W3C_Recommendation]? He provided an omnibus 
  review so you need to wade through a lot of other stuff, but he made what 
  I think are some valuable comments on the proposal for Obsolete and Rescinded 
  Recs that I think are relevant to your points here
  '''SZ Assessment:''' There were no further messages or request so it eeems
  that No Action is Require.
  '''No Action Require'''