[Servercert-wg] [Ext] Referencing RFCs

[Tim Hollebeek]

Yes, I meant "obsoletes", thanks.

-Tim

> -----Original Message-----
> From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of
> Paul Hoffman via Servercert-wg
> Sent: Thursday, October 24, 2019 3:43 PM
> To: servercert-wg at cabforum.org
> Subject: Re: [Servercert-wg] [Ext] Referencing RFCs
> 
> On 10/24/19 7:59 AM, Tim Hollebeek via Servercert-wg wrote:
> > There is, perhaps, a legitimate point to be made about whether approved
> IETF Errata are normative or not.  We haven’t run into that situation yet, but it
> may arise in the future.
> 
> I believe that the IETF has no official position on this, and nor does the RFC
> Editor. There have been examples of errata that have been accepted and later
> removed. Your best bet is to point to the RFC and refer to the erratum by URL,
> saying that the erratum is normative for the document you are publishing.
> 
> > Another point which has been discussed a few times is how to handle RFCs
> that update an existing RFC (this is true of RFC 5280, for example).  I’ve heard
> both opinions expressed over the years, but the BRs themselves are silent on
> the issue.
> 
> Are you speaking of "obsolete" or "update"?
> 
> If RFC $y obsoletes RFC $x, everything that relies on RFC $x should be updated
> to refer to RFC $y. There are sometimes reasons not to, but they often fall into
> the category of "that's too hard" which is kinda lame. IETF decisions to
> obsolete an old RFC are usually careful and have strong reasoning.
> 
> If RFC $n updates RFC $m, RFC $m is not affected. There are many reasons to
> update, usually tangential to the core of an RFC. If you want the value of RFC
> $n in addition to RFC $m, you need to reference them both for the reader to
> understand the complete picture.
> 
> --Paul Hoffman
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191028/57b8c3e2/attachment.p7s>