Re: Obsolete vs rescinded vs superseded recommendations

> On Aug 10, 2016, at 12:33, Chaals McCathie Nevile <chaals@yandex-team.ru> wrote:
> 
> Hi Florian,
> 
> 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.

I'm ok with that. I think there is a distinction, but I don't think it is critical enough to insist on a separate category if others don't feel that way (which seems to be the case).

> But there are some gems in here too…
> 
> Did you read Ian Jacobs' recent review comments? 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.

I skimmed through it. I'll have another look.

>> 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.
> 
> Yes, but this isn't a new problem. It can be annoying, but it doesn't seem, in practice, to have led to a serious amount of trouble. While I don't think we should be blind to the issue, I think it's not a very big one in practice.

As long as We Obsolete instead of Rescind for such documents, then there is no problem, neither in practice nor in theory.

>> Is the current practice of including prominent (albeit ad-hoc) warning notes in such specifications sufficient? Should they be rescinded?
> 
> IMHO we could reasonably *rescind* CSS 2.0 - but before we tried to do the same to HTML 3.2 and 4 we should clarify the situation for HTML in email, which is close to HTML 5.x in webmail clients and those that incorporate a modern HTML engine, but not so much in Outlook's MS Word-based engine.

For documents that predate the patent policy, I am not sure that there is that much of a difference between rescinding and obsoleting anyway. But for the sake of the argument, if we pretend that these documents had been new enough to be under the patent policy, why do you think Rescinding would be more appropriate than Obsoleting? Even if we have moved beyond a certain stage of a technology, and the newer version are partly incompatible with the old ones, I see not reason to waive the patent policy. Implementing CSS2.0 instead of 2.1 or 3+ in 2016 seems like a pretty bad idea (hence Obsoletion), but if we had patent protection on it, what do we gain by giving it up?

> But I'm not sure the Director would agree.
> 
>> 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 don't think the additional marginal value of a "Superseded" justifies its cost, since I think it covers one of the cases where documents should be obsoleted.

Fair enough.

> I do think that some of the ideas you outline below would be improvements on our current proposal for obsoletion.
> 
> [...]
> 
>> - The superseded REC MUST have (a) link(s) to the document(s) that supersede it
> 
> This isn't the case. One reason is that while in some cases a document is made obsolete by another document - e.g. HTML 3.2 and CSS 2.0, in others the entire technology has been replaced by something else as is the case IMHO for e.g. CC/PP and PICS.
> 
> There is a further case where there isn't really a replacement, but the world seems to have gone in a different direction. For example P3P aims to solve a problem that seems to still exist, and that doesn't seem to have a different solution, but the world is not implementing P3P, and doesn't seem *likely* to do so.
> 
> For the second, and especially the third case, marking the document Obsolete is recognising reality. And if the reality changes e.g. because people suddenly start implementing P3P en masse, then we should, with Keynes, keep up :)

Sure. I think this requirement makes sense for the Superseded subset of Obsolete document, not in the general case. If we're not distinguishing between the two, could we keep this but turn the MUST into a SHOULD?

>> - 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).
> 
> Agreed. I think it is fair to require that an Obsolete Rec's updated version explain *why* it was made Obsolete, which is a generalisation of this that neither conflicts with nor supersedes (ha ha) it.

Sounds good to me. How about combining the "MUST explain why it is Obsoleted" with the "SHOULD link to documents that supersede / replaces / conflict, if any"?

>> 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.
> 
> I think that case is a generally applicable rationale for restoring an obsolete document.

Sure. I just think that rationales that apply to other subsets of obsolete don't apply to  the superseded subset. But that's not terribly important.

 - Florian

Received on Wednesday, 10 August 2016 04:38:36 UTC