This section provides guidance about reference entries commonly found in Internet-Drafts and RFCs; it is non-exhaustive. These are the recommended reference formats for differnet types of references, and authors should follow this guidance when drafting their documents. Note: Being included on this page does NOT imply endoresement or recognition of any kind.
Send comments or questions about this guidance or other reference issues to the RFC Production Center (RPC) at rfc-editor@rfc-editor.org or open an issue on GitHub.
Format
[CITE-TAG] Last name, First initial., Ed. (if applicable), “RFC Title”,
Subseries number (if applicable), RFC number, DOI, Date of publication,
<https://www.rfc-editor.org/info/rfc#>.
Example
[RFC3080] Rose, M., “The Blocks Extensible Exchange Protocol Core”, RFC 3080,
DOI 10.17487/RFC3080, March 2001, <https://www.rfc-editor.org/info/rfc3080>.
Using the BibXML Service for RFCs
Add RFC references using the BibXML service. For example:
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1234.xml"/>
For more information on inserting references in RFCXML, see
https://authors.ietf.org/en/references-in-rfcxml.
This guidance overrides Section 4.8.6.3 of RFC
7322.
Internet Standards (STDs) and Best Current Practices (BCPs) may
consist of a single RFC or multiple RFCs. When an STD or BCP as a
whole is referenced, the reference entry should include ALL of the
RFCs comprising that subseries at the time of writing. The authors
should refer to specific RFC numbers as part of the text (not as
citations) and cite the subseries number. The URI to the STD or BCP
info page is to be included. The text should appear as follows:
See RFC 3552 [BCP72].
Format
[CITE-TAG] Internet Standard XXX, <https://www.rfc-editor.org/info/std#>. At the
time of writing, this STD comprises the following:
Last name, First initial., Ed. (if applicable), “RFC Title”, STD XXX, RFC
number, DOI number, Date of publication,
<https://www.rfc-editor.org/info/rfc#>.
Example
[STD80] Internet Standard 80, <https://www.rfc-editor.org/info/std80>. At the
time of writing, this STD comprises the following:
Cerf, V., “ASCII format for network interchange”, STD 80, RFC 20, DOI
10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>:
Using the BibXML Service for Subseries:
Add references for subseries documents using the BibXML service. For example:
<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0237.xml"/>
For more information on inserting references in RFCXML, see https://authors.ietf.org/en/references-in-rfcxml.
This guidance overrides Section 4.8.6.5 of RFC 7322.
The format for references to errata reports is as follows:
Format
[CITE-TAG] RFC Errata, Erratum ID number, RFC number, <URI>.
Example
[Err3607] RFC Errata, Erratum ID 3607, RFC 4627,
<https://www.rfc-editor.org/errata/eid3607>.
Referencing "Reported" Errata:
Errata in the Reported state should not be referenced; they are not considered stable.
Note on Updating or Obsoleting RFCs with Errata
If your Internet-Draft "Updates" or "Obsoletes" another RFC and addresses errata filed against those RFCs, we recommend asking your Area Director (AD) or Stream Manager to verify the relevant reported errata.
Note that the top-level URL is used when referring to a group of registries and/or specific registries within the group.
This guidance was developed in coordination with IANA. See “Guidance for RFC Authors” for more information.
Format
[CITE-TAG] IANA, “Registry Name”, <URL>.
Example
[IANA] IANA, “ANCP Message Types”, <https://www.iana.org/assignments/ancp>.
Format
[CITE-TAG] IANA, “Registry Group”, <URL>.
Example
[IANA-ANCP] IANA, “Access Node Control Protocol (ANCP)”,
<https://www.iana.org/assignments/ancp>.
Add reference entries for IANA registries and registry groups using the BibXML Service. For example:
<xi:include href="https://bib.ietf.org/public/rfc/bibxml8/reference.IANA.ancp_message-types.xml"/>
For more information on inserting references in RFCXML, see https://authors.ietf.org/en/references-in-rfcxml.
References to Internet-Drafts may only appear as informative references. See Section 4.8.6.4 of RFC 7322 for more information.
Format
[CITE-TAG] Last name, First initial., Ed. (if applicable) and
First initial. Last name, Ed. (if applicable), "I-D Title", Work in
Progress, Internet-Draft, draft-string-NN, Day Month Year,
<https://datatracker.ietf.org/doc/html/draft-something>.
Example
[RFCED-MODEL] Hoffman, P. and A. Rossi, "RFC Editor Model (Version 3)", Work in
Progress, Internet-Draft, draft-editorial-rswg-rfc9280-updates-04, 31 July 2025,
<https://datatracker.ietf.org/doc/draft-editorial-rswg-rfc9280-updates/>.
Using the BibXML Service for I-Ds
Add reference entries for I-Ds using the BibXML service. For example:
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.rpc-rfc7322bis.xml"/>
For more information on inserting references in RFCXML, see https://authors.ietf.org/en/references-in-rfcxml.
Format
[CITE-TAG] IETF, "Working Group Name (abbreviation)", <URL>.
Example
[CDNI] IETF, "Content Delivery Networks Interconnection
(cdni)",<https://datatracker.ietf.org/wg/cdni/charter/>.
Note: Finding a Working Group’s Datatracker page and the appropriate
URL
A list of active IETF Working Groups is available on Datatracker.
Use the WG’s Datatracker URL. Both /charter and /about point to the same page. Aim for consistency within a document.
Note that, while a WG can have a GitHub repo, and RFCs can point to these, the text shouldn’t imply that the repo is the main information page for the working group. There should be a link to the WG’s Datatracker page instead. A link to a WG’s repo can be found on their Datatracker page under “Additional Resources”.
Format
[CITE-TAG] Sender Name, First Initial., "Subject: Subject line",
message to the listname mailing list, DD Month YYYY, <URL>.
Example
[RPC-Meeting] Mahoney, J., "[rfc-i] RFC Production Center open meeting - Nov
19", message to the rfc-interest mailing list, 12 November 2025,
https://mailarchive.ietf.org/arch/msg/rfc-interest/czuWiLuFOiuXLmRw3Z6Syt9QXM4/.
Note:
For a message on an IETF mailing list, use mailarchive.ietf.org URLs. To find a WG mailing list, check https://datatracker.ietf.org/wg/ and/or https://datatracker.ietf.org/group/concluded/.
Mailing list addresses of the format “@lists.ietf.org” (mostly WG lists) have not been valid since 2005.
Format
[CITE-TAG] Name of mail archive, "Name of Mailing List" Archive, <URL>.
Example
[SAAG_list] IETF Mail Archive, "saag Archive",
<https://mailarchive.ietf.org/arch/browse/saag/>.
Format
[CITE-TAG] Presenter Last Name, First initial.,
"Presentation Title", IETF # Proceedings, Month Year, <URL>.
Example
[MAPRG] Bajpai, V., "Measuring YouTube Content Delivery over IPv6",
IETF 99 Proceedings, July 2017,
<https://datatracker.ietf.org/meeting/99/materials/slides-99-maprg-measuring-youtube-content-delivery-over-ipv6-00>.
Note: Finding proceedings pages
Past IETF meetings are listed here:
https://www.ietf.org/how/meetings/past/
Meeting materials can also be found on each working group’s meeting page on Datatracker. For example,
https://datatracker.ietf.org/wg/quic/meetings/
Format
[CITE-TAG] Last name, First initial., Ed. (if applicable), "Title",
Name of IAB Workshop, Date, <URL>.
Example
[MARTINEZ] Martínez-Cervantes, L. M. and R. Guevara-Martínez,
"Community Networks and the Quest for Quality", IAB Workshop on
Barriers to Internet Access of Services (BIAS), January 2024,
<https://www.ietf.org/slides/slides-biasws-community-networks-and-the-quest-for-quality-00.pdf>.
Format
[CITE-TAG] Presenter Last Name, First initial.,
"Presentation Title", Name of IAB Workshop, Date, <URL>.
Example
[RAMESH-1] Ramesh, R., "Investigating the VPN Ecosystem through the
lens of Security, Privacy, and Usability", IAB Workshop on Barriers to
Internet Access of Services (BIAS), January 2024,
<https://datatracker.ietf.org/meeting/interim-2024-biasws-03/materials/slides-interim-2024-biasws-03-sessa-investigating-the-vpn-ecosystem-through-the-lens-of-security-privacy-and-usability-00>.
The main purpose of this section is to provide authors with a
non-exhaustive list of commonly used references to promote
consistent formatting of reference entries in RFCs and
I-Ds. Organizations and sources are included in this list for the
sole purpose of providing examples to authors. The inclusion of an
organization in this list does not represent an endorsement of that
organization's standards, specifications, or other any documentation.
Format
[CITE-TAG] 3GPP, "Title", 3GPP TR/TS TR or TS Number, <URL>.
Example
[Spec-3GPP] 3GPP, "System architecture for the 5G System (5GS)", 3GPP
TS 23.501,
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144>.
Referencing Specific Versions and/or Releases of 3GPP Specifications
If referencing a specific version from a specific release by 3GPP, include the version and release number, the date of publication, and the URL pointing to that version. For example:
[TR.26.857] 3GPP, "5G Media Service Enablers", 3GPP TR 26.857, Version
1.0.0, Release 18, September 2022,
<https://ftp.3gpp.org//Specs/archive/26_series/26.857/26857-100.zip>.
Format
[CITE-TAG] ETSI, "Title", Document
identifier, Version number (if applicable), Date, <URL>.
Example
[nfv-framework] ETSI, "Network Functions Virtualisation (NFV); Architectural
Framework", ETSI GS NFV 002, V1.2.1, December 2014,
<https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_NFV002v010201p.pdf>.
Note:
A list of the types of standards, specifications, and reports produced by ETSI is available on their website.
Format
[CITE-TAG] IEEE, "Title", IEEE Std #, DOI, Year, <URL or DOI URL>.
Example
[IEEE802.1AX] IEEE, "IEEE Standard for Local and Metropolitan Area Networks
-- Link Aggregation", IEEE Std 802.1AX-2020, DOI
10.1109/IEEESTD.2020.9105034, 2020,
<https://ieeexplore.ieee.org/document/9105034>.
When creating reference entries for IEEE Standards, we recommend using URLs for IEEExplore. For example: https://ieeexplore.ieee.org/document/9363693.
Format
[CITE-TAG] Organization, "Title", Standard Series number, Date, <URL>.
Example
[SWID] ISO/IEC, "Information technology - IT asset management - Part 2: Software
identification tag", ISO/IEC 19770-2:2015, October 2015,
<https://www.iso.org/standard/65666.html>.
Format
[CITE-TAG] ITU-T, "Title", ITU-T Recommendation #, Date, <URL>.
Example
[Y3301] ITU-T, "Functional requirements of software-defined
networking", ITU-T Recommendation Y.3301, September 2016,
<http://www.itu.int/rec/T-REC-Y.3301-201609-I/en>.
Format
[CITE-TAG] NIST, “Title of FIPS Publication”, NIST FIPS Number, DOI, Date of
Publication, <URL>.
Example
[NIST_FIPS_180_4] NIST, “Secure Hash Standard”, NIST FIPS 180-4, DOI
10.6028/NIST.FIPS.180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.
Format
[CITE-TAG] Last name, First initial., Ed. (if applicable), “Title of
SP”, National Institute of Standards and Technology, NIST SP Number, DOI, Date of Publication, <URL>.
Example
[NIST_SP_800-233] Chandramouli, R., Butcher, Z., and J. Callaghan, “Service Mesh
Proxy Models for Cloud-Native Applications”, National Institute of Standards and Technology, NIST SP 800-233, DOI
10.6028/NIST.SP.800-233, October 2024,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-233.pdf>.
The following guidance is adapted from the Unicode Consortium's reference guidance.
[UNICODE] The Unicode Consortium, "The Unicode Standard",
<https://www.unicode.org/versions/latest/>.
[UNICODE-V17] The Unicode Consortium, "The Unicode Standard", Version
17.0.0, ISBN 978-1-936213-35-1, 2025,
<https://www.unicode.org/versions/Unicode17.0.0/>.
WHATWG provides "commit snapshots" for their standards. Since WHATWG publishes "Living Standards" which are regularly updated and changed, we recommend adding a URL to this commit snapshot in the reference in an annotation.
The URL for the commit snapshot can be found by clicking the "Snapshot as of this commit" link provided at the main URL for a Living Standard.
For more information on WHATWG commit snapshots, see:
https://whatwg.org/faq#change-at-any-time.
Format
[CITE-TAG] WHATWG, "Title", WHATWG Living Standard,
<URL>.
Commit snapshot: <Commit Snapshot URL>
Example
[URL-PATTERN] WHATWG, "URL Pattern", WHATWG Living Standard,
<https://urlpattern.spec.whatwg.org/>.
Commit snapshot:
<https://urlpattern.spec.whatwg.org/commit-snapshots/d13ebead18003059a83ca4a25240e5cafc066c4c/>
Note on Anchor Permanence in WHATWG Living Standards
WHATWG guidance on the permanence of anchors in WHATWG Living Standards notes:
Since Living Standards are continually evolving, the set of anchors in
a document is not static, and some anchors could disappear over time.
WHATWG recommends filing an issue on an Living Standard's GitHub if another standards organization "wishes to ensure an anchor is permanently available in the canonical Living Standard". For example:
https://github.com/whatwg/html/issues/11646.
Please inform the RPC during the intake process if you are waiting on WHATWG to approve making anchors in a Living Standard permanent.
W3C provides two URLs for their documents:
We recommend including both URLs in reference entries to W3C documents using the following format:
Format
[CITE-TAG] Last name, First initial., Ed. (if applicable), "Title",
W3C Recommendation, Date of Publication, <URL>.
Latest version available at <https://www.w3.org/TR/xml/>.
Example
[W3C.XML1.0] Bray, T., Ed., Paoli, J., Ed., Sperberg-McQueen, C.M., Ed., Maler,
E., Ed., and F. Yergeau, Ed., "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", W3C Recommendation, 26 November 2008, <https://
www.w3.org/TR/2008/REC-xml-20081126/>.
Latest version available at <https://www.w3.org/TR/xml/>.
Note:
The "latest version" annotation can be included in a reference in RFCXML like so:
<annotation>Latest version available at <eref target="URL" brackets="angle"/>.</annotation>
This section expands on the guidance for using URIs in RFCs from Section 4.8.6.1 of RFC 7322:
The use of URIs in references is acceptable, as long as the URI is
the most stable (i.e., unlikely to change and expected to be
continuously available) and direct reference possible. The URI will
be verified as valid during the RFC editorial process.If a dated URI (one that includes a timestamp for the page) is
available for a referenced web page, its use is required.Note that URIs may not be the sole information provided for a
reference entry.
Assessing Reference URI/URL for Permanence and Stability
From Section 4.8.6.1 of RFC
7322:
The use of URIs in references is acceptable, as long as the URI is
the most stable (i.e., unlikely to change and expected to be
continuously available) and direct reference possible. The URI will
be verified as valid during the RFC editorial process.
When assessing URLs for stability, consider the following:
"Link rot" and "content drift"
"Link rot" is the phenomenon where a URL fails to point to its original target. This is often the result of the resource being moved to a new address or becoming permanently unavailable.
"Content drift" is the phenomenon where a URL is functional, but the content available at that URL changes over time - for example, an organization's homepage content changing due to a name change or being folded into another organization.
Using permanent identifiers and/or archived URLs may help preserve the stability of a reference's URL and prevent a reference from being affected by link rot or content drift.
For more information on link rot and content drift see:
Using Permanent URLs - i.e., "permalinks", Digital Object Identifiers (DOIs), etc.
If there is a permanent identifier for the reference, we recommend including it in the reference entry.
Using Archived URLs
If there is a concern about the longevity of the URL, we recommending using an archived URL in the reference. For example, using the Internet Archive Wayback Machine:
Example of an Internet Archive Wayback Machine URL:
https://web.archive.org/web/20260122123558/https://www.rfc-editor.org/
Format
[CITE-TAG] Author (if available), "Title (if available)", Date (if available), <URL>.
Example
[RFC-Editor] "RFC Editor", <https://www.rfc-editor.org/>.
Titles for References to Websites.
Some websites may not have exact titles or the title may not be clear. If this is the case, a description may be used instead.
For example:
Microsoft, "Microsoft home page", <https://www.microsoft.com/en-us/>.
Dates for References to Websites
If the website being referenced includes a publication date or "Last modified" date (or equivalent), include it as the date for the reference.
Format
[CITE-TAG] Wikipedia, "Title", Date of most recent edit, <Dated URL>.
Example
[Magnet] Wikipedia, "Magnet URI scheme", March 2013,
<https://en.wikipedia.org/w/index.php?title=Magnet_URI_scheme&oldid=546892719>.
Permanent Links for Wikipedia Reference Entries
Wikipedia provides a permanent link under the "Tools" tab. A list of permanent links is also available under the "View history" tab.
When constructing the reference target in RFCXML, replace the ‘&’ in the versioned URL with “&”:
<reference anchor="Magnet"
target="https://en.wikipedia.org/w/index.php?title=Magnet_URI_scheme&oldid=546892719">
Format
[CITE-TAG] Last name, First initial., Ed. (if applicable), "Title",
Name of Journal, vol. # (if applicable), no. # (if applicable), Date,
pp. #, DOI (if applicable), <URL>.
Example
[Dijkstra] Dijkstra, E., "A note on two problems in connexion with
graphs", Numerische Mathematik, vol. 1, pp. 269-271, DOI
10.1007/BF01386390, December 1959,
<https://link.springer.com/article/10.1007/BF01386390>.
Format for Journal Volume and Issue Numbers
For journal articles with volume and issue numbers we recommend using the following style:
Volume 1 = vol. 1
Issue 1 = no. 1
Format
[CITE-TAG] Last name, First initial., Ed. (if applicable), "Title",
Name of Conference, Date, pp. #, DOI (if applicable), <URL>.
Example
[MiningPsQs] Heninger, N., Durumeric, Z., Wustrow, E., and
J. A. Halderman, "Mining Your Ps and Qs: Detection of Widespread Weak
Keys inNetwork Devices", 21st USENIX Security Symposium (USENIX
Security 12), August 2012,
<https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger>.
Format
[CITE-TAG] Last name, First initial., Ed. (if applicable), "Title",
Name of periodical / publication, Date, <URL>.
Example
[Wired-IETF] Borsook, P., "How Anarchy Works", Wired, October 1995,
<https://www.wired.com/1995/10/ietf/>.
Format
[CITE-TAG] Last name, First initial., "Title", M.A./M.S./Ph.D. Dissertation, Awarding
Institution, Date, <URL (if available)>.
Example
[Shannon1940] Shannon, C., "A Symbolic Analysis of Relay and Switching
Circuits", M.S. Thesis, Massachusetts Institute of Technology, 1940,
<https://dspace.mit.edu/handle/1721.1/11173>.
References to web-based public code repositories may only appear as informative references.
Format
[CITE-TAG] "Name or description of repository", commit hash, Date, <URL>.
Example
[pysaml2] “Python implementation of SAML2”, commit 7135d53, 6 March 2018,
<https://github.com/IdentityPython/pysaml2>.
Note:
Format of reference entries:
Format
[CITE-TAG] "filename", commit hash, date, <URL>.
Example
[pysaml2-config] "config.py", commit 74dc24d, 26 September 2023,
<https://github.com/IdentityPython/pysaml2/blob/master/src/saml2/config.py>.
Format
[CITE-TAG] Last name, First initial., Ed. (if applicable), "Title",
arXiv#, DOI (if applicable), Date, <URL>.
Example
[Shors96] Shor, P. W., "Polynomial-Time Algorithms for Prime Factorization and
Discrete Logarithms on a Quantum Computer", arXiv:quant-ph/9508027, DOI
10.48550/arXiv.quant-ph/9508027, January 1996, <https://arxiv.org/abs/quant-ph/9508027>.
Format
[CITE-TAG] Last name, First initial., Ed. (if applicable), "Title",
Cryptology ePrint Archive, Paper #, Date (year), <URL>.
Example
Courtois, N., "Security Evaluation of GOST 28147-89 In View Of International
Standardisation", Cryptology ePrint Archive, Paper 2011/211, 2011,
<https://eprint.iacr.org/2011/211>.