[rfc-i] Relation to other RFCs - Updates

Martin Rex mrex at sap.com
Thu May 3 09:43:24 PDT 2012


SM wrote:
> [following up on rfc-i]
> At 10:50 02-05-2012, Martin Rex wrote:
> >The rfc2223 document title is "Instruction to RFC Authors".  The Updates:
> >header has a purely editorial meaning for the *new* document, but the
> >result can certainly be very technical for the *old* document!
> According to rfc-editor.org, RFC 2223 is not part of the style 
> guide.  There is currently a request at 
> http://www.rfc-editor.org/pipermail/rfc-interest/2012-April/003307.html 
> about changing the status of RFC 2223.
> >Updates: should only be used if the change is supposed to apply not only
> I am ok with what you said.  However, the published information only says:
>    "Specifies an earlier document whose contents are modified or
>     augmented by the new document.  The new document cannot be
>     used alone, it can only be used in conjunction with the
>     earlier document."
> >But there is a certain mess in the meta-data of published RFCs.
> If that is your opinion, and given that you have been around for some 
> time, picture what people with less familiarity would say.

rfc2223 section 12 (defining a narrow scope for Updates: and Replaces:
as RFC meta-data) seems to be similar to Section 2.11 (page 9) of
this document:


There are 3 kinds of changes to an *EXISTING* document:

  1.) errata for an existing RFC
  2.) newer RFC that updates an existing RFC
  3.) newer RFC that obsoletes an existing RFC

and the respecitive scope of the "completely replacing":

  1.) typically a few words or sentences
  2.) typically paragraphs or sections
  3.) the complete document

The purpose of _all_3_ is to guide RFC reader into finding the
most current/accurate information describing the technology that
was originally described in the *EXISTING* document.

So if someone wants to newly implement TLSv1.0 in order to interoperate
with the installed base of TLSv1.0, then the current RFC meta-data tells
such an implementor that rfc2246 (TLSv1.0) has been "completely replaced"
by rfc4346 (TLSv1.1) which again has been "completely replaced" by
rfc5246 (TLSv1.2).  But this is clearly factually incorrect, because
it will be impossible to implement TLSv1.0 from rfc5246(TLSv1.0).
Instead, rfc2246 will be required (and rfc4346 & rfc5246 are
entirely expendable for implementing TLSv1.0).

so for consistency,
  IPv6 does not "Obsolete" (=completely replace) IPv4,
  HTTP/1.1 does not "Obsolete" HTTP/1.0
  TLSv1.2 does not "Obsolete" TLSv1.1 or TLSv1.0

Another common inconsistency in the meta-data of RFCs about Updates: is
the use in situations where the references earlier document is not
actually changed, so that a meta-information "Applies To" or "Extends"
might be appropriate, but the narrowly scoped "Updates:" is not.

Does the definition of a new mime-type update the Internet Message format,
any Mime specs or any HTTP/1.x specs? (Usually, it doesn't).  Does the
definition of "IP over YYY" (YYY= Ethernet, TokenRing, Avian Carriers,...)
Update the IP protocol spec?  Usually, it doesn't.

The "cannot be used alone" seems to be a very poor guidance for determining
whether "Updates:" meta-data is appropriate.  The vast majority of
documents have "normative references", which turns them into "cannot be
used alone" documents.  But that doesn't mean that all documents in
the normative Reference section should receive an "Updates:" meta-data.
Only those earlier documents for which the new document contains
revised information that completely replaces clearly defined parts
of the earlier document that are applicable to readers/implementors
of _the_earlier_document_ should receive an "Updated by:" meta-data.


More information about the rfc-interest mailing list