[rfc-i] Relation to other RFCs - Updates

SM sm at resistor.net
Thu May 3 11:34:14 PDT 2012


Hi Martin,
At 09:43 03-05-2012, Martin Rex wrote:
>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:

Yes.

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

Ok.  but it may be difficult to convince RFC authors about that.

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

I am ok with the "incorrect" part.  I am aware that there is an 
erratum discussing that.

>so for consistency,
>   IPv6 does not "Obsolete" (=completely replace) IPv4,

These are two different technologies.

>   HTTP/1.1 does not "Obsolete" HTTP/1.0

It should if the goal is to encourage the person to implement the 
latest version of a specification.

>   TLSv1.2 does not "Obsolete" TLSv1.1 or TLSv1.0

The same rationale for HTTP applies.

RFC 5321 obsoletes RFC 2821.  RFC 2821 obsoletes RFC 2821.  These is 
a normative reference in RFC 5321 to RFC 821.  There is an 
explanation from the editor of the RFC about why that approach was 
taken.  There is probably an explanation for HTTP/1.1.

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

I would look at this from a reader perspective.  At the end of the 
day, it is a matter of clarity.  It is complicated in practice as we 
assume that the reader will be aware of all the intricacies in reading a RFC.

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

One of the editors of those document(s) commented on that.

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

The normative reference is, in my humble opinion, about documents the 
person should read to understand the content of the RFC.  The "cannot 
be used alone" could be viewed as a side-effect of not having document sets.

It difficult to have exact guidance.  Here's something that was 
posted to some list:

   "the IETF only allows about 5 authors to be listed at the top
    of the draft"

Half-truths tend to be turned into the absolute truth.  The same 
argument applies for "Updates:".  Even what I said above could be wrong.

Regards,
-sm 



More information about the rfc-interest mailing list