Template talk:IETF RFC

RFCs on citations templates and the flagging free-to-read sources

See

• Wikipedia:Village pump (proposals)#Access locks: Visual Design RFC
• Wikipedia:Village pump (proposals)#Access Locks: Citation Template Behaviour RFC

Headbomb {talk / contribs / physics / books} 17:03, 29 October 2016 (UTC)

Better links:

• Wikipedia:Village pump (proposals)/Archive 135#Access locks: Visual Design RFC
• Wikipedia:Village pump (proposals)/Archive 135#Access Locks: Citation Template Behaviour RFC

I'm not really sure how these discussions are related to this template, though. --MZMcBride (talk) 19:52, 3 January 2017 (UTC)

Template output change

• RFC 1234
• RFC 1234

These outputs are now identical. --MZMcBride (talk) 00:30, 3 January 2017 (UTC)

This should not have been done. Reverted. Headbomb {talk / contribs / physics / books} 13:16, 3 January 2017 (UTC)

Hi Headbomb. Okay. Can you please explain further? --MZMcBride (talk) 16:50, 3 January 2017 (UTC)

The output of this template is designed to match that of other identifier templates, like {{OCLC}}, {{PMID}} and so on, and is also designed to match the output of {{cite xxx}} templates. It is not designed to match whatever magic thing the software does (especially since this will be phased out in future releases of mediawiki). Headbomb {talk / contribs / physics / books} 18:16, 3 January 2017 (UTC)

Ah, okay. We should probably update Template:IETF RFC/doc to note this, then. I'm not sure how anyone is/was expected to know that this template purportedly needs a very particular format.

The eventual deprecation of magic links is why I took an interest in this template. I looked at the template's usage and thought it would be safe enough to change since nothing is really using it. For what it's worth, some people don't really like "overlinking" to articles such as ISBN or Request for Comments or Case citation or whatever in templates like this. It's somewhat similar to the arguments against date linking.

In going through the instances of RFC magic links, a lot of them are inline external links currently, which probably need to be converted to references. I may end up using this template, but not for inline cases, as I first thought, but instead putting it inside <ref> tags. --MZMcBride (talk) 19:47, 3 January 2017 (UTC)

In <ref> tags I would probably use {{Cite IETF}}. — Franklin Yu (talk) 15:53, 26 April 2018 (UTC)

Any reference about phasing out of the RFC magic? — Franklin Yu (talk) 15:53, 26 April 2018 (UTC)

Basic error checking

Maybe we could include some basic error checking, like max number (right now, we're in the 8.1k range, so >10k for a while would be an error), as well as verifying every input is a number. --Izno (talk) 01:07, 23 May 2017 (UTC)

Protection

@The Anome: There are only 200 transclusions. Why was this fully protected? --Izno (talk) 12:36, 30 May 2017 (UTC)

That number is going to increase significantly, as the magic links bot does its work. I would expect the template to be linked in at least 2,000 articles shortly, and to thus be a significant vandalism target. As the template has only one, well-defined, purpose, I don't see any current need for it to be generally editable; it can be unprotected to be edited if necessary. -- The Anome (talk)

@The Anome: That sounds like a rationale for template protection, not full protection, then. --Izno (talk) 13:23, 30 May 2017 (UTC)

You're right. I've changed the protection level to template protection. -- The Anome (talk) 13:27, 30 May 2017 (UTC)

@The Anome: The same applies to {{ISMN}}. Can you change this to template protection as well? --Matthiaspaul (talk) 14:08, 27 August 2017 (UTC)

@Matthiaspaul:  Done -- The Anome (talk) 20:21, 27 August 2017 (UTC)

@The Anome: Thank you.

Meanwhile, the {{error-small}} template has become a highly used template due to its use in other highly used templates. Can you add template protection to this one, please? Thanks. --Matthiaspaul (talk) 23:56, 6 September 2017 (UTC)

@Matthiaspaul: Thanks for spotting this!  Done -- The Anome (talk) 10:44, 7 September 2017 (UTC)

Indeed, the protection is dubious for only 200 pages, fondly remembering "my" Template:!. –84.46.53.185 (talk) 01:47, 3 December 2019 (UTC)

Requested feature: section links

I just created the following link: [https://tools.ietf.org/html/rfc4086#section-6.1.3 RFC 4086 section 6.1.3] "Traditional Pseudo-random Sequences", which renders as RFC 4086 section 6.1.3 "Traditional Pseudo-random Sequences". Since I am referencing a section, making the link point to that section makes all sorts of sense. But I couldn't find a way to create this using {{IETF RFC}}. I don't currently have a suggested parameter name, and I'm not sure I put the right words inside the link, but maybe something like this is of broader interest? 104.153.72.218 (talk) 09:52, 3 November 2017 (UTC)

Where do you need this link? In references {{Cite IETF}} is better IMO. —— Franklin Yu (talk) 15:44, 26 April 2018 (UTC)

|sectionn= seems reasonable, but the current template seems like too much meta template to try to stuff that in. --Izno (talk) 16:22, 26 April 2018 (UTC)

plainlink=yes

The {{IETF RFC|125|126|127|plainlink=yes|}} example 125, 126, 127 is odd, I expected a class="plainlinks" RFC 125, RFC 126, RFC 127 effect. –84.46.53.185 (talk) 01:51, 3 December 2019 (UTC)

New site datatracker.ietf.org

The https://tools.ietf.org/html/rfcXXX now redirects to https://datatracker.ietf.org/doc/html/rfcXXX. For example https://tools.ietf.org/html/rfc114 redirects to https://datatracker.ietf.org/doc/html/rfc114. Maybe the template should be updated accordingly? Same for Template:Cite IETF. Thanks --Prikryl (talk) 08:15, 7 June 2021 (UTC)

Prikryl,  Done. GeneralNotability (talk) 01:09, 8 June 2021 (UTC)

@GeneralNotability Thanks. --Prikryl (talk) 04:46, 8 June 2021 (UTC)

@GeneralNotability What about Template:Cite IETF?

rfc-editor.org or datatracker.ietf.org

Currently the https://tools.ietf.org/html/rfcXXX is redirected to https://www.rfc-editor.org/rfc/rfcXXX.html. I would prefer www.rfc-editor.org rather than datatracker.ietf.org.

Example: https://www.rfc-editor.org/rfc/rfc9110.html vs https://datatracker.ietf.org/doc/html/rfc9110

May I update this template to link to the www.rfc-editor.org? Wdpp (talk) 11:44, 4 February 2023 (UTC)

I second this. The rfc-editor variant is much easier to read and navigate for newer RFCs. See https://www.rfc-editor.org/rfc/rfc9559 vs https://datatracker.ietf.org/doc/html/rfc9559

Another options would be to link to https://www.rfc-editor.org/info/rfc9559. That is where the Digital object identifier is pointed to currently. From that page, the reader would have to choose between HTML, PDF, text or XML. A deeper link to the HTML variant seems reasonable though. Ktf (talk) 07:13, 22 October 2024 (UTC)

Related templates?

Are there IETF foo templates for other types of IETF documents, e.g., BCP, STD? My first thought was that, e.g., {{cite IETF|BCP=}}. would serve the purpose, but that requires |title=. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:15, 15 March 2023 (UTC)

Violates WP:NOELBODY

What's the justification for including external links when the guideline says not to? Often where I see this being used, e.g. at WebSocket, the link should be used as a reference, not as an inline EL. SmartSE (talk) 22:16, 6 November 2023 (UTC)

See also #Discussion at WP:ELN § Templates being used to embed external links into articles. fgnievinski (talk) 02:32, 9 August 2024 (UTC)

Proposal to use variadic arguments instead of hardcoded 1-9

I based the implementation of {{autnum}} on {{IETF RFC}}, as a wrapper that calls {{Catalog lookup link}} with args 1-9 passed through (except expanded to 1-100 because I wanted more than 9 in some cases). I recently made a change there, to remove the hardcoded 1-n list of arguments, which might be beneficial to apply here too.

Potential caveat: this removes the #expr evaluation currently done on each argument. I didn't find it necessary for {{autnum}}, but maybe someone is relying on it here in a way I haven't seen.

−

{{Catalog lookup link|{{#expr:{{{1|}}}|}}|{{#expr:{{{2|}}}|}}|{{#expr:{{{3|}}}|}}|{{#expr:{{{4|}}}|}}|{{#expr:{{{5|}}}|}}|{{#expr:{{{6|}}}|}}|{{#expr:{{{7|}}}|}}|{{#expr:{{{8|}}}|}}|{{#expr:{{{9|}}}|}}|article-link={{#ifeq:{{yesno-no|{{{plainlink|}}}}}|yes||{{#ifeq:{{yesno-yes|{{{link|}}}}}|no||RFC (identifier)}}}}|article-name={{#ifeq:{{yesno-no|{{{plainlink|}}}}}|yes||RFC}}|link-prefix=https://datatracker.ietf.org/doc/html/rfc|list-leadout={{{leadout|}}}}}

+

{{#invoke:params|concat_and_call|Catalog lookup link|article-link={{#ifeq:{{yesno-no|{{{plainlink|}}}}}|yes||{{#ifeq:{{yesno-yes|{{{link|}}}}}|no||RFC (identifier)}}}}|article-name={{#ifeq:{{yesno-no|{{{plainlink|}}}}}|yes||RFC}}|link-prefix=https://datatracker.ietf.org/doc/html/rfc|list-leadout={{{leadout|}}}}}

Thoughts? DefaultFree (talk) 13:02, 3 December 2023 (UTC)

I am the author of Module:Params and I came across this discussion by following Special:WhatLinksHere/Module:Params while checking that everything is OK. Indeed it does not seem necessary to me to use {{#expr:...}}. If the purpose is that of filtering out parameters whose names and values are not numbers, it is possible to add ...|with_name_matching|^%d+$|with_value_matching|^%d+$|... to {{#invoke:params}}. If instead the purpose is that of trimming leading and trailing whitespaces, there is ...|trimming_values|.... I have no idea how {{Catalog lookup link}} works, but I suppose one of these three modifiers would be needed too: either ...|squeezing|... or ...|clearing|... or ...|filling_the_gaps|... (please check the documentation). Most likely the code posted by DefaultFree would become:

{{#invoke:params|trimming_values|with_name_matching|^%d+$|with_value_matching|^%d+$|squeezing|concat_and_call|Catalog lookup link|article-link={{#ifeq:{{yesno-no|{{{plainlink|}}}}}|yes||{{#ifeq:{{yesno-yes|{{{link|}}}}}|no||RFC (identifier)}}}}|article-name={{#ifeq:{{yesno-no|{{{plainlink|}}}}}|yes||RFC}}|link-prefix=https://datatracker.ietf.org/doc/html/rfc|list-leadout={{{leadout|}}}}}

--Grufo (talk) 20:02, 28 May 2024 (UTC)

Ok, I see now. {{Catalog lookup link}} is not needed at all:

{{#invoke:params|sequential|trimming_values|with_value_matching|^%d+$|squeezing|setting|h/i/l|{{If|eq|{{yesno-no|{{{plainlink|}}}}}|yes||{{#ifeq:{{yesno-yes|{{{link|}}}}}|no|RCF|[[RFC (identifier)|RCF]]}} }}|, |{{If||{{{leadout|}}}| {{{leadout}}}|,}} |for_each|[https://datatracker.ietf.org/doc/html/rfc$@ $@]}}

--Grufo (talk) 20:49, 28 May 2024 (UTC)

Discussion at WP:ELN § Templates being used to embed external links into articles

 You are invited to join the discussion at WP:ELN § Templates being used to embed external links into articles. -- Marchjuly (talk) 02:43, 2 January 2024 (UTC)

Now archived at Wikipedia:External_links/Noticeboard/Archive_25#h-Templates_being_used_to_embed_external_links_into_articles-20231231215600. fgnievinski (talk) 02:33, 9 August 2024 (UTC)

Use in article body

Fgnievinski has added guidance that this template not be used in the article body. I want to make sure there's local consensus on this since {{IETF RFC}} is used quite frequently in article bodies and cleaning this up would be quite a chore. ~Kvng (talk) 00:06, 14 August 2024 (UTC)

The rationale is explained in #Violates WP:NOELBODY. fgnievinski (talk) 03:31, 14 August 2024 (UTC)

See also Wikipedia:External links/Noticeboard/Archive 25#Templates being used to embed external links into articles, linked above.

@Fgnievinski, or anyone, could you perhaps explain your view in a way that sounds like "I personally think it makes articles better/worse" instead of "There's some WP:UPPERCASE that we're required to follow"? I'm having trouble understanding whose ox is being gored if these links are provided. WhatamIdoing (talk) 06:50, 14 August 2024 (UTC)

It's well explained in WP:CS:EMBED. fgnievinski (talk) 18:17, 14 August 2024 (UTC)

Yes, but that's for citing sources, not for providing information. My question is, if we would accept an external link to a relevant document at Wikisource in the middle of an article, then why should we not equally accept an external link to a relevant IETF RFC document in the middle of an article?

Compare:

• The adoption of the US Standard Reference Data Act in 1968 was a key moment in the debate over metrication.^[book]
• RFC 527 was the first of the April Fools' Day Request for Comments and started a tradition of officially sanctioned humor.^[book]

Neither of those uses are embedded refs.

NOELBODY says there are "rare exceptions", and the footnote says "Links to Wiktionary and Wikisource can sometimes be useful. Other exceptions include use of templates like {{external media}}..." Why do you think this shouldn't be one of those "Other exceptions"? (I assume that you think it shouldn't, but I suppose I haven't said that you believe that it shouldn't. So far, you've only said that you believe that it's against the written rules.) WhatamIdoing (talk) 18:31, 14 August 2024 (UTC)

As quoted, links to sister projects are fine. External media is a well sanctioned exception. The rest is a slippery slope: why not allow extlinks to ISOs, too? Most extlinks to RFCs would better serve the reader if provided inside a full reference, with title, date, etc. Allowing the current template to be used in the body of articles only serves well a hurried editor. Some extlinks to RFCs might even be turned into internal links. Currently, both usages (linking proper and citations to full-text content) are conflated in {{IETF RFC}}. fgnievinski (talk) 20:25, 14 August 2024 (UTC)

We have traditionally (since 2003?) had links to IETF RFCs (also PMIDs, ISBNs, and Bible verses) in articles. It has not resulted in us sliding down a slippery slope towards including anything and everything during the last 20 years, so I doubt that it will happen in the future.

This has been an accepted practice for many years. Yes, sometimes it's the wrong choice. I agree that we should link to internal articles (e.g., RFC 2324) when those exist. But I see no basis for saying that editors shouldn't ever put these links into the body of an article. WhatamIdoing (talk) 00:08, 15 August 2024 (UTC)

Inline extlinks to RFC are opaque, it forces the reader to follow the extlink to get to know basic information like title and year of publication. It shifts the burden of seeking such bibliographic information from the editor to the reader. Extlinks peppered in the article body is a lazy practice, we can do better. fgnievinski (talk) 01:33, 15 August 2024 (UTC)

If someone is clicking on RFC 2119, do you think they want to know the title and year of publication, or do you think they want to look at the contents? I can't speak for everyone, but I can tell you that when I click that link, I am never interested in the title or date. I'm usually checking the definition for should or may.

External links peppered in the article body if and only if they ought to be citations is a lazy practice. External links deliberately placed in the article body when the actual text of the document might be wanted (or needed) by the reader is not a lazy practice. WhatamIdoing (talk) 17:35, 15 August 2024 (UTC)

Someone shouldn't need to click on any external link to find out the title of the publication, in this case: "Key words for use in RFCs to Indicate Requirement Levels". The publication number, 2119, reveals nothing about the subject, except perhaps to someone who already knows it. That's why editors often include the RFC title in the body of the article. If you'd like to provide links to full sources, the best place is at the end of that particular full reference, saying "Available at: ..." There's no reason to server an impatient reader and provide an external link as soon as possible, a reasonable reader can find it at the list of references. Plus, {{ieft rfc}} is often invoked multiple times for the same RFC in the same Wikipedia article, cluttering the prose with repeated internal links to RFC (most editors won't bother to use "link=no") and providing the same external link over and over again. Last, you assume everyone would like to read the full text, when most readers would prefer to have a chance to find out the publication's title before deciding whether or not they'd like to leave the Wikipedia website or app. fgnievinski (talk) 03:11, 16 August 2024 (UTC)

The duplication may be due to bot-like replacements when the magic word was removed, rather than a deliberate editorial decision. WhatamIdoing (talk) 03:57, 16 August 2024 (UTC)

I've looked around and frequently {{IETF RFC}} is followed by the the publication title -- clearly something that should go in the list of references, for improved readability. To avoid interrupting the prose with bibliographic information, this handicap tends to lend itself to the creation of bullet lists of RFCs. When it's intermingled with wikilinks, it gets messy pretty quickly; see, e.g., Microsoft_Open_Specification_Promise#Published_protocols. fgnievinski (talk) 04:48, 15 August 2024 (UTC)

A list of publications should have the names, including what people call them: The White Album, the Camel Book, RFC 2119, USB, etc. I think the list you linked is okay, though it might look prettier as a table.

However, contemplate List of HTTP status codes, which says "Emphasised words and phrases such as must and should represent interpretation guidelines as given by RFC 2119", or XHTML, which has a list of "Media type recommendation (in RFC 2119 terms)". The RFC is an explanatory glossary for understanding the Wikipedia article. It does not support the claim being made. It's therefore WP:EL territory instead of WP:RS. WhatamIdoing (talk) 17:47, 15 August 2024 (UTC)

The RFC number is non-informative for the non-initiated; the average reader needs more information, like the publication's title, before they can decide if they'd like to access the full text. That specific example is particularly illuminating because Wikipedia has an article discussing it: RFC 2119. Wikipedia should always give preference to an internal link about any topic. Even {{external media}} is discouraged if a sister project has something related. We should discourage hasty editos from slapping extlinks to RFCs and make them look around the related Wikipedia coverage. RFCs are just a publication -- they even have a DOI, where the bibliographic information is deposited. fgnievinski (talk) 03:56, 16 August 2024 (UTC)

In the case of RFC 2119, the publication number is the WP:COMMONNAME. It is used in more than twice as many Wikipedia articles as the title. The title of the RFC is never used in a Wikipedia article without the common name, and the title is only given in lists and citations.

Your insistence that the largely ignored name needs to be provided for the sake of the reader is like saying we need to always spell out Travels into Several Remote Nations of the World. In Four Parts. By Lemuel Gulliver, First a Surgeon, and then a Captain of Several Ships, even though nobody uses the official title and everyone uses the short name.

To put some numbers on that, Google Books says there are 959 books using the exact quoted string "RFC 2119" and a mere 27 that use the title without giving the number. 97% of sources use the publication number; 3% don't. Two-thirds of them give only the RFC number. Yes, let's think of the readers, but let's think about what the reader will see in the real world, which is "RFC 2119" and not "Key words for use in RFCs to Indicate Requirement Levels". WhatamIdoing (talk) 04:05, 16 August 2024 (UTC)

And 592 books giving both the title and the series item number, that's more than half of the books giving only the RFC number. We should give it all – number and extlink, but also title and author and year of publication. That's what citations are for. If the number is a common name, please write in in prose, next to the citation superscript. There's no need to distract the reader with green arrow icons. fgnievinski (talk) 07:52, 16 August 2024 (UTC)

I think we're talking about different things. So here's a sentence in an article:

"As the HTTP/1.0 standard did not define any 1xx status codes, servers must not send a 1xx response..."

The words must not are tagged with a footnote that says: "Emphasised words and phrases such as must and should represent interpretation guidelines as given by RFC 2119"

Do you think that, in this footnote, RFC 2119 is a citation that supports the article content? For example, do you think that if you go to RFC 2119, you will find something about when and whether 1xx status codes may be sent? WhatamIdoing (talk) 16:37, 16 August 2024 (UTC)

Without the publication title, it's not possible to guess if the cited publication is about the main topic (HTTP), where it might define its own terminology, or if it's a general publication about a shared vocabulary. We shouldn't withhold such important information from the reader. fgnievinski (talk) 23:37, 16 August 2024 (UTC)

I don't have any difficulty interpreting the sentence. Consider:

• Emphasised words represent interpretation as given by RFC 2119.
• Emphasised words represent interpretation as given by Merriam-Webster.
• Emphasised words represent interpretation as given by Karp.

No matter what source you name in the sentence, you can glork from the context that it's either a document or an author, right? WhatamIdoing (talk) 00:04, 17 August 2024 (UTC)

Yes, "RFC 2119” looks like it's a technical document. Can we reveal its title? I'm not disputing the provision of an external link. But I insist to give more: at the very least the document title, in addition to the external link. Let's encourage editors to provide more bibliographic context about the external resource. Regardless of the use in the Wikipedia article, for supporting a content claim or its interpretation, RFCs are genuine publications. If you just hate the standard "ref" element for citations, at least use an explanatory footnote to provide the title and external link. There's just no exemption in effect for external links to RFCs in the body of the article, sorry. fgnievinski (talk) 02:40, 18 August 2024 (UTC)

Why should we "reveal" a title that is rarely used in practice?

Do you similarly think that when List of the Beatles' instruments says "Near the end of the sessions for the White Album, he obtained a natural-tone five-piece Ludwig Hollywood set", or when The Fab Faux talks about "a track-by-track rendering of The White Album", we need to "reveal" the official title of the album, in addition to using the common name? WhatamIdoing (talk) 04:02, 18 August 2024 (UTC)

We're talking about hundreds of technical documents, most of which are far obscure. The RFC number means nothing to the average Wikipedia reader. This is not IETF's encyclopedia and even their datatracker website gives the title. It's the reader's right to know when offering an external link. fgnievinski (talk) 01:28, 19 August 2024 (UTC)

Is it the reader's right to know the official title, or the WP:COMMONNAME? WhatamIdoing (talk) 01:41, 19 August 2024 (UTC)

Both. fgnievinski (talk) 06:08, 20 August 2024 (UTC)

Thanks for bringing that up. I frequently see citations being used to merely point at relevant documents, rather than their intended purpose of directly supporting the claims that precede the citation. Whatever we do, we shouldn't make that problem worse. jlwoodwa (talk) 03:28, 20 August 2024 (UTC)

How do you expect the reader to find the relevant document, if it's not a well known publication and external links are discouraged in the body of Wikipedia articles? fgnievinski (talk) 06:13, 20 August 2024 (UTC)

Where in WP:MOS does it say that citations are only for citing sources? WP:EL explicitly gives other permitted uses. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:14, 20 August 2024 (UTC)

@Chatul: Could you specify which part of WP:EL you mean? I've read through the guideline, and I don't see anything like that. What it does say is This guideline does not restrict linking to websites that are being used as sources to provide content in articles., which is exactly the intended purpose that I'm talking about. jlwoodwa (talk) 15:55, 20 August 2024 (UTC)

I was thinking of Sites that contain neutral and accurate material that is relevant to an encyclopedic understanding of the subject and cannot be integrated into the Wikipedia article due to copyright issues,[d] amount of detail (such as professional athlete statistics, movie or television credits, interview transcripts, or online textbooks), or other reasons. in WP:EL § What can normally be linked -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:24, 20 August 2024 (UTC)

I'm confused – that doesn't seem to have anything to do with citations. It's about what kinds of external links are acceptable in the external links section. jlwoodwa (talk) 17:52, 20 August 2024 (UTC)

Re: "This guideline does not restrict linking to websites that are being used as sources to provide content in articles". The above should be interpreted in conjunction with the following: "Guidelines for sourcing, which include external links used as citations, are discussed at ... Wikipedia:Citing sources." and "This guideline does not apply to inline citations or general references, which should appear in the 'References' or 'Notes' section". So, WP:EL permits external links only within the citation text, not directly in the body of the article. fgnievinski (talk) 03:41, 22 August 2024 (UTC)

@Fgnievinski, you have asserted that Wikipedia:External links "permits external links only within the citation text, not directly in the body of the article". When I read WP:EL (and, just so you know, I have written a good deal of it, so I am familiar with its contents) I find this statement:

"With rare exceptions, external links should not be used in the body of an article. [Note] Links to Wiktionary and Wikisource can sometimes be useful. Other exceptions include use of templates like {{external media}}, which is used only when non-free and non-fair use media cannot be uploaded to Wikipedia."

See those words I've put in bold? They say that the guideline does permit external links outside of citation text. Which should be obvious, since the ==External links== section is "outside of citation text".

Also, it's generally bad form to change relevant parts of guidelines while you're in a dispute over them. WhatamIdoing (talk) 18:03, 22 August 2024 (UTC)

No one is disputing the trivial case of external links in the External links section. The rest are rare exceptions. The use of RFC EL is pervasive, often by the dozens in the same article. fgnievinski (talk) 00:38, 23 August 2024 (UTC)

I'd expect it to be used "by the dozens" in a list of IETF RFCs.

I opened ten articles that use this template. In them I found:

• One that used the template only inside ref tags.
• Two that used the template only in the ==External links== section.
• Three that used the template in lists (about which, see WP:ELLIST)
• Four that use the template in sentences, e.g., "

WhatamIdoing (talk) 01:06, 23 August 2024 (UTC)

The first two types are not being disputed, so they can be used aplenty. The third one, WP:ELLIST, is not a blank check for using EL in lists in the body of the article, as per section heading, "#Links normally to be avoided", further discussed as: " fgnievinski (talk) 02:14, 23 August 2024 (UTC)

This is in the context of your I frequently see citations being used to merely point at relevant documents, rather than their intended purpose of directly supporting the claims that precede the citation. The text that I quoted is from a subsection of WP:EL § What to link and applies to links in citations just as much as to links in an external links section. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:00, 22 August 2024 (UTC)

Why would it apply to links in citations? The very first sentence in WP:ELPOINTS says that This guideline does not apply to inline citations or general references. jlwoodwa (talk) 18:56, 22 August 2024 (UTC)

I'm not the one that wrote I frequently see citations being used to merely point at relevant documents, rather than their intended purpose of directly supporting the claims that precede the citation.; I'm the one that challenged it. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:02, 22 August 2024 (UTC)

I don't think that this is a case of "used as sources to provide content in articles". As this seems to be a point of confusion, I'll start a separate thread for that. Maybe if we can figure out whether these are "sources" or "external links", we'll be able to have a more productive conversation. WhatamIdoing (talk) 17:00, 20 August 2024 (UTC)

Is it technically feasible to write a template that;

1. Tests for the existence of a page with the specified RFC(s) as its (their) name(s), and if found, links to it (them)
2. Generates or refers to previously generated footnotes using {{cite IETF|RFC=}} and bibliographic data pulled from IETF?

Something like {{IETF|RFC|5321|5322|5335}} might produce RFC 5321, 5322, 5335 the first time, and reuse the <ref>...</ref> with <ref name= /> if the same RFC is referenced later. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:07, 15 August 2024 (UTC)

You might have to post the titles and other data (they don't change) on wiki, but all of those ideas are technically feasible. WhatamIdoing (talk) 17:32, 15 August 2024 (UTC)

Chatul you may find {{ref RFC}} to be helpful. ~Kvng (talk) 22:50, 22 August 2024 (UTC)

References

External link vs Reliable source

How this template gets used in articles

What's in the article	Does the linked RFC support the statement?
Most RFCs use a common set of terms such as "MUST" and "NOT RECOMMENDED" (as defined by RFC 2119 and 8174), augmented Backus–Naur form (ABNF) (RFC 5234) as a meta-language, and simple text-based formatting, in order to keep the RFCs consistent and easy to understand.	No, the RFC says nothing about whether "Most RFCs" actually use it or what the purpose is, so it's an external link providing supplemental information.
The same number of decimal places should be used in each value, including trailing zeroes.	No, the RFC says nothing about the number of decimal places or trailing zeroes. It's functioning like a link to a dictionary, which is an explicitly approved reason to have an external link in the body of an article.
RFC 2119 Key words for use in RFCs to Indicate Requirement Levels	No, because this is in ==External links==
# Title Date published RFC 2119 Key words for use in RFCs to Indicate Requirement Levels March 1997	Yes, and already contains the title
The IETF (Internet Engineering Task Force) defines shall and must as synonymous terms denoting absolute requirements, and should as denoting a somewhat flexible requirement, in RFC documents.	Yes, and is already [imperfectly] formatted as a source

WhatamIdoing (talk) 17:11, 20 August 2024 (UTC)

Looking at these examples of actual use, I don't think that a one-size-fits-all approach is viable. WhatamIdoing (talk) 21:46, 20 August 2024 (UTC)

Here's the ideal version (I've used citer.toolforge.org to generate the citation texts):

How this template gets used in articles

What's in the article	Does the linked RFC support the statement?
Most RFCs use a common set of terms such as "MUST" and "NOT RECOMMENDED" (as defined by RFCs 2119 and 8174), augmented Backus–Naur form (ABNF) as a meta-language (as per RFC 5234), and simple text-based formatting, in order to keep the RFCs consistent and easy to understand (as available in the RFC Index).
The same number of decimal places should be used in each value, including trailing zeroes.
Bradner, Scott O. "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels". IETF Datatracker. Retrieved 2024-08-22.
# Title Date published RFC 2119 Key words for use in RFCs to Indicate Requirement Levels March 1997
The IETF (Internet Engineering Task Force) defines shall and must as synonymous terms denoting absolute requirements, and should as denoting a somewhat flexible requirement, in RFC documents.

PS: WP:EL permits external links in the article body only to sister projects such as the Wiktionary, not any unaffiliated dictionary or glossary. fgnievinski (talk) 03:35, 22 August 2024 (UTC)

The same footnote that mentions Wiktionary also mentions "Other exceptions". It is not a complete list.

Even if I agreed that your ideal was, in fact, the ideal, I don't think that a single template can serve for both the table (where we agree that a full bibliographic citation would be inappropriate) and for the last one, when the RFC is really being used as a reliable source.

Also, note that WP:ELCITE bans the use of full citation templates in the ==External links== section, so your third one is a violation of the guideline. WhatamIdoing (talk) 18:09, 22 August 2024 (UTC)

When providing a publication for the reader to consult at the end of the article, it's more informative to label the section as "Further reading" and give more citation details. The External links section is meant more for an entry point for further navigation, such as the website home page, a directory or index of resources. fgnievinski (talk) 01:01, 23 August 2024 (UTC)

I do not agree, Wikipedia:External links does not agree, and Wikipedia:Further reading does not agree. WhatamIdoing (talk) 01:06, 23 August 2024 (UTC)

Go MOS:FURTHER: "publications that would help interested readers learn more about the article subject". Then check MOS:ELLAYOUT: "recommended relevant websites, each accompanied by a short description. (...) Depending on the nature of the link contents, this section may be accompanied or replaced by a 'Further reading' section." fgnievinski (talk) 01:54, 23 August 2024 (UTC)

See also Wikipedia:Further reading, which says "Some articles may also or instead have an External links section; editors will occasionally merge the two if both are very short. When an article contains both sections, some editors prefer to list websites and online works in the External links section."

It is more typical to have an ==External links== with documents that are free to read than to have a ==Further reading== section containing links to online-only documents. IMO the decision should be made individually at each article. Articles are ~50% more likely to have an external links section. WhatamIdoing (talk) 03:07, 23 August 2024 (UTC)

References