RFC 8174
E185718
RFC 8174 is an IETF document that clarifies the interpretation of requirement-level keywords like “MUST” and “SHOULD” in technical specifications, updating the guidance originally given in RFC 2119.
All labels observed (2)
| Label | Occurrences |
|---|---|
| Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words | 1 |
| RFC 8174 canonical | 1 |
How this entity was disambiguated
This entity first appeared as the object of triple T1649231 — resolving that mention is where its identity was fixed. The disambiguator weighed these candidate entities and picked the highlighted one (or “None”, minting a new entity). This is how homonymy is resolved: the same surface form can point to different entities.
NED1
Entity disambiguation (via context triple)
gpt-5-mini-2025-08-07
Target entity: RFC 8174 Context triple: [BCP 14, relatedTo, RFC 8174]
-
A.
RFC 8314
RFC 8314 is an Internet standard that specifies the use of mandatory encryption (TLS) for email submission and access protocols to improve the security of email communications.
-
B.
RFC 8200
RFC 8200 is the Internet Engineering Task Force (IETF) standard that specifies the core protocol architecture and operation of Internet Protocol version 6 (IPv6).
-
C.
RFC 7143
RFC 7143 is the Internet Engineering Task Force (IETF) standard that defines the updated core specification for the iSCSI (Internet Small Computer Systems Interface) protocol used for block-level storage over IP networks.
-
D.
RFC 9114
RFC 9114 is the Internet standard that specifies HTTP/3, the version of the Hypertext Transfer Protocol that runs over the QUIC transport protocol.
-
E.
RFC 6146
RFC 6146 is an IETF standard that specifies the behavior and requirements for NAT64, enabling IPv6-only clients to communicate with IPv4 servers through protocol translation.
- F. None of above. chosen
- G. Unsure - the case is ambiguous/there is not enough information to decide.
NED2
Entity disambiguation (via description)
gpt-5-mini-2025-08-07
Target entity: RFC 8174 Target entity description: RFC 8174 is an IETF document that clarifies the interpretation of requirement-level keywords like “MUST” and “SHOULD” in technical specifications, updating the guidance originally given in RFC 2119.
-
A.
RFC 8314
RFC 8314 is an Internet standard that specifies the use of mandatory encryption (TLS) for email submission and access protocols to improve the security of email communications.
-
B.
RFC 8200
RFC 8200 is the Internet Engineering Task Force (IETF) standard that specifies the core protocol architecture and operation of Internet Protocol version 6 (IPv6).
-
C.
RFC 7143
RFC 7143 is the Internet Engineering Task Force (IETF) standard that defines the updated core specification for the iSCSI (Internet Small Computer Systems Interface) protocol used for block-level storage over IP networks.
-
D.
RFC 9114
RFC 9114 is the Internet standard that specifies HTTP/3, the version of the Hypertext Transfer Protocol that runs over the QUIC transport protocol.
-
E.
RFC 6146
RFC 6146 is an IETF standard that specifies the behavior and requirements for NAT64, enabling IPv6-only clients to communicate with IPv4 servers through protocol translation.
- F. None of above. chosen
Statements (49)
| Predicate | Object |
|---|---|
| instanceOf |
IETF standard document
ⓘ
Request for Comments ⓘ |
| area | General ⓘ |
| author |
Alexey Melnikov
NERFINISHED
ⓘ
Barry Leiba ⓘ Benjamin N. Kaduk ⓘ |
| bcpNumber | BCP 14 ⓘ |
| category | Best Current Practice ⓘ |
| clarifies |
ambiguity between uppercase and lowercase forms of RFC 2119 keywords
ⓘ
that BCP 14 keywords are to be interpreted only when in all capitals ⓘ |
| defines |
clarified interpretation of requirement-level keywords
ⓘ
normative language usage for BCP 14 keywords ⓘ |
| format |
HTML
ⓘ
PDF ⓘ text ⓘ |
| hasBCPKeyword | BCP 14 ⓘ |
| hasRFCNumber | 8174 ⓘ |
| intendedFor |
authors of IETF technical specifications
ⓘ
readers of IETF technical specifications ⓘ |
| isPartOf |
Best Current Practice
ⓘ
surface form:
Best Current Practice 14
|
| keyword |
MAY
ⓘ
MUST ⓘ MUST NOT ⓘ OPTIONAL ⓘ RECOMMENDED ⓘ REQUIRED ⓘ SHALL ⓘ SHALL NOT ⓘ SHOULD ⓘ SHOULD NOT ⓘ |
| language | English ⓘ |
| obsoletes | none ⓘ |
| publicationDate | May 2017 ⓘ |
| publishedBy |
Internet Engineering Task Force
ⓘ
surface form:
IETF
Internet Engineering Task Force ⓘ |
| publisher | RFC Editor ⓘ |
| relation |
refines the guidance originally given in RFC 2119
ⓘ
used as a boilerplate reference for normative language sections ⓘ |
| scope | IETF documents that use BCP 14 keywords ⓘ |
| series |
RFCs
ⓘ
surface form:
RFC
|
| status | Best Current Practice ⓘ |
| stdStatus | Best Current Practice ⓘ |
| stream |
Internet Engineering Task Force
ⓘ
surface form:
IETF
|
| subject |
normative language
ⓘ
requirements levels in technical specifications ⓘ |
| title |
RFC 8174
self-linksurface differs
ⓘ
surface form:
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
|
| updates | RFC 2119 ⓘ |
| url | https://www.rfc-editor.org/rfc/rfc8174 ⓘ |
| year | 2017 ⓘ |
How these facts were elicited
The pipeline generated the facts above by prompting gpt-5.1 with this entity's name + description and the instruction below.
Instruction
You are a knowledge base construction expert. Given a subject entity and a description of it, return factual statements that you know for the subject as a JSON list of dictionaries(triples), where keys must be "subject", "predicate" and "object". The number of facts may be very high, between 25 to 50 or more, for very popular subjects. For less popular subjects, the number of facts can be very low, like 5 or 10. # Requirements - If you don't know the subject at all, return an empty list. - If the subject is not a named entity, return an empty list. - Include at least one triple where predicate is "instanceOf". - Do not get too wordy. - Separate several objects into multiple triples with one object.
Input
Subject: RFC 8174 Description of subject: RFC 8174 is an IETF document that clarifies the interpretation of requirement-level keywords like “MUST” and “SHOULD” in technical specifications, updating the guidance originally given in RFC 2119.
Referenced by (2)
Full triples — surface form annotated when it differs from this entity's canonical label.