Re: Obsolete vs rescinded vs superseded recommendations

> On Aug 8, 2016, at 21:15 , Florian Rivoal <florian@rivoal.net> wrote:
> 
> The rescinding process looks appropriate when "W3C discovers burdensome patent claims", but since rescinded documents are no longer covered by the patent policy, it is less clear that it is a good fit for recommendations that would be fine on their own, but are replaced by and are in conflict with later specifications.

Correct.  Rescinded is for specs with actual problems (almost certainly IPR problems).

> 
> The process to obsolete recommendations seems somewhat more relevant for such documents, but that's not what the process document calls for.

Oh, it was intended to cover this case.  If that’s not clear, we should make it so.

> 
> 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).

I think this is a good example of Obsoleted: we think that there are better, more recent specs but they are not an incremental version of the spec. in question.

> 
> 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?

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).

> 
> 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.

Right.  Or we decide that seuperseding HTML with XHTML didn’t actually happen and we reverse ourselves… :-).  (That was a joke, ok, please.)

Dave Singer

singer@mac.com

Received on Tuesday, 9 August 2016 16:03:52 UTC