Re: [rfc-i] "Obsoleting" a perfectly valid document

Hello Carsten,

if somebody considers RFC 7049 as outdated and no longer useful, but RFC 7049bis as current, then there is no problem,
as long as the person sticks to RFC 7049bis and it is compatible with RFC 7049.

The shorter the wording, the better.  The “Status of this Memo”, “Copyright Notice”, RFC2119-KEYWORDS/Terminology
definitions repeated everywhere, lead to wasting considerable amount of papers, when I print RFCs, and this counts over
the whole globe, for every person that prints an RFC.  It will be much better, if there is a single RFC containing a
Status, Copyright Notice, and Keyword definitions (incl. the word obsoleted) that are valid both for that RFC and for
each other RFC that references the first RFC.  Think on all saved paper and time saved skipping that sections.

The RFCs are interconnected and to understand the concepts in one RFC one has to read several of them, so needs to get
used to their style.

So, instead of the word “obsoleting”, another single word can be taken, like “This RFC replaces/substitutes/supersedes
RFC x".  The details go in a section, describing the differences with the replaced document and from that section it
shall be evident, that this is a revised edition.

I think at the end it is up to the authors, here you, to decide how to word this.

Regards
  Дилян

On Thu, 2019-07-04 at 20:31 +0200, Carsten Bormann wrote:
> Hi Дилян,
> 
> sorry for not giving more context.  The text I don’t like actually now is in https://tools.ietf.org/html/draft-ietf-cbor-7049bis-06, twice, in the abstract and at the end of the introductory text of Section 1.
> 
> I do understand the language we use inside the IETF for document revisions, and I agree that the sentence we wrote is clear for readers that know that special language.  Actually, giving that information is necessary for the reason you give:  So people know which documents they no longer need to read.
> 
> However, for someone who isn’t as familiar with RFCs, there is a significant danger of misunderstanding the term “obsoletes”: 
> 
> > obsolete | ˌɑbsəˈlit | 
> > verb [with object] chiefly US 
> > cause (a product or idea) to be or become obsolete by replacing it with something new: “we’re trying to stimulate the business by obsoleting last year’s designs”. 
> [cited from New Oxford American Dictionary]
> 
> But the idea or the product are not obsolete, only the specification has been revised after 5 years of experience with people using it.  People use RFC numbers both to refer to the actual RFC and to the concept defined in there (as in “an RFC822 message”, of course usually with the number of an obsoleted RFC…).
> 
> My message was a request for help writing this up in a better way, but also a repeat of my ceterum censeo that some of the language we use to describe our processes is incomprehensible to outsiders.
> 
> Paul Hoffman has fixed up my proposed text a bit (https://github.com/cbor-wg/CBORbis/pull/89), and with the support here I think this can go in.  Still, I would like to hear about ways other people have handled similar situations — it is quite tedious to extract this kind of information from some 1140 RFCs that obsolete others.
> 
> (Just to give one example: RFC 2822, which obsoleted RFC 822 and was then obsoleted by RFC 5322, never says so except in the head of the front page.  It also goes ahead and defines a whole section of “obsolete syntax”, which retains some no longer desirable parts of RFC 822 only to keep some measure of backward compatibility.  None of this changed in RFC 5322.  Oh, and RFC 822 obsoletes RFC 733, but uses that term again only in its front page head, and uses “revises” in the text to describe the not insignificant technical changes that were made.)
> 
> Grüße, Carsten
> 

_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest