Here is an actual example. When 'Guidelines for Writing an IANA Considerations Section in RFCs' was published it got the BCP # 26. The document behind it was RFC 2434.
Later an update was published, namely RFC 5226, that obsoleted RFC 2434. Now, BCP 26 points to RFC 5226, see https://tools.ietf.org/html/bcp26 On 04/03/2015 07:57 PM, Hannes Tschofenig wrote: > I learned something new: we can reference a BCP (instead of an RFC) and > even if the RFC gets up-dated we will still have a stable reference. > (See Stephen's response to my question below). > > This is what we should do for our documents when we reference TLS in the > future. We would reference the yet-to-become BCP (currently UTA-TLS > document) and we essentially point to the recommended usage for TLS > (version, ciphersuite, everything). > > Isn't that great? > > -------------------------------------------------------- > > On 02/04/15 19:09, Hannes Tschofenig wrote: >> Hi Stephen, >> >> if I understand it correctly, you are saying if we reference a BCP # >> (instead of the RFC) then a revised RFC will get the same BCP #. I have >> never heard about that and if that's indeed true that would be cool. I >> might also have misunderstood your idea though. > > Yep, that's it. XML2RFC makes it hard but you can do it, worst > case via an RFC editor note > > S. > >> > > > > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
