Output examples
38 calls fixed as output snapshots by npm run snapshot (tests/snapshot/cases.mjs). Each output is collapsed; open it to see the first 60 lines, and follow the link for the full file. <generatedAt> replaces the timestamp.
get_rfc_structure
structure-793
Arguments: get_rfc_structure
json
{
"rfc": 793
}Output (136 lines)
text
# structure-793
tool: get_rfc_structure
args: {"rfc":793}
--- json ---
{
"metadata": {
"title": "TRANSMISSION CONTROL PROTOCOL",
"number": 793,
"date": "1981-09",
"category": "std"
},
"sections": [
{
"number": "1",
"title": "INTRODUCTION",
"subsections": [
{
"number": "1.1",
"title": "Motivation"
},
{
"number": "1.2",
"title": "Scope"
},
{
"number": "1.3",
"title": "About this Document"
},
{
"number": "1.4",
"title": "Interfaces"
},
{
"number": "1.5",
"title": "Operation"
}
]
},
{
"number": "2",
"title": "PHILOSOPHY",
"subsections": [
{
"number": "2.1",
"title": "Elements of the Internetwork System"
},
{
"number": "2.2",
"title": "Model of Operation"
},
{
"number": "2.3",
"title": "The Host Environment"
},
{
"number": "2.4",
"title": "Interfaces"
},
… (136 lines)structure-1035
Arguments: get_rfc_structure
json
{
"rfc": 1035
}Output (337 lines)
text
# structure-1035
tool: get_rfc_structure
args: {"rfc":1035}
--- json ---
{
"metadata": {
"title": "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
"number": 1035,
"date": "1987-11",
"category": "std",
"abstract": "This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication."
},
"sections": [
{
"number": "1",
"title": "STATUS OF THIS MEMO"
},
{
"number": "2",
"title": "INTRODUCTION",
"subsections": [
{
"number": "2.1",
"title": "Overview"
},
{
"number": "2.2",
"title": "Common configurations"
},
{
"number": "2.3",
"title": "Conventions",
"subsections": [
{
"number": "2.3.1",
"title": "Preferred name syntax"
},
{
"number": "2.3.2",
"title": "Data Transmission Order"
},
{
"number": "2.3.3",
"title": "Character Case"
},
{
"number": "2.3.4",
"title": "Size limits"
}
]
}
]
},
{
"number": "3",
"title": "DOMAIN NAME SPACE AND RR DEFINITIONS",
"subsections": [
{
… (337 lines)structure-2068
Arguments: get_rfc_structure
json
{
"rfc": 2068
}Output (1104 lines)
text
# structure-2068
tool: get_rfc_structure
args: {"rfc":2068}
--- json ---
{
"metadata": {
"title": "Hypertext Transfer Protocol -- HTTP/1.1",
"number": 2068,
"date": "1997-01",
"category": "std",
"stream": "IETF",
"abstract": "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]"
},
"sections": [
{
"number": "1",
"title": "Introduction",
"subsections": [
{
"number": "1.1",
"title": "Purpose"
},
{
"number": "1.2",
"title": "Requirements"
},
{
"number": "1.3",
"title": "Terminology"
},
{
"number": "1.4",
"title": "Overall Operation"
}
]
},
{
"number": "2",
"title": "Notational Conventions and Generic Grammar",
"subsections": [
{
"number": "2.1",
"title": "Augmented BNF"
},
{
"number": "2.2",
"title": "Basic Rules"
}
]
},
{
"number": "3",
"title": "Protocol Parameters",
"subsections": [
{
"number": "3.1",
"title": "HTTP Version"
},
… (1104 lines)structure-8949
Arguments: get_rfc_structure
json
{
"rfc": 8949
}Output (444 lines)
text
# structure-8949
tool: get_rfc_structure
args: {"rfc":8949}
--- json ---
{
"metadata": {
"title": "Concise Binary Object Representation (CBOR)",
"docName": "draft-ietf-cbor-7049bis-16",
"number": 8949,
"date": "2020-12",
"category": "std",
"stream": "IETF",
"abstract": "The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.\n\n This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format."
},
"sections": [
{
"number": "1",
"title": "Introduction",
"anchor": "introduction",
"subsections": [
{
"number": "1.1",
"title": "Objectives",
"anchor": "objectives"
},
{
"number": "1.2",
"title": "Terminology",
"anchor": "terminology"
}
]
},
{
"number": "2",
"title": "CBOR Data Models",
"anchor": "cbor-data-models",
"subsections": [
{
"number": "2.1",
"title": "Extended Generic Data Models",
"anchor": "extended-generic-data-models"
},
{
"number": "2.2",
"title": "Specific Data Models",
"anchor": "specific-data-models"
}
]
},
{
"number": "3",
"title": "Specification of the CBOR Encoding",
"anchor": "encoding",
"subsections": [
{
"number": "3.1",
"title": "Major Types",
"anchor": "majortypes"
… (444 lines)structure-9114
Arguments: get_rfc_structure
json
{
"rfc": 9114
}Output (516 lines)
text
# structure-9114
tool: get_rfc_structure
args: {"rfc":9114}
--- json ---
{
"metadata": {
"title": "HTTP/3",
"docName": "draft-ietf-quic-http-34",
"number": 9114,
"date": "2022-06",
"category": "std",
"stream": "IETF",
"abstract": "The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3."
},
"sections": [
{
"number": "1",
"title": "Introduction",
"anchor": "introduction",
"subsections": [
{
"number": "1.1",
"title": "Prior Versions of HTTP",
"anchor": "prior-versions-of-http"
},
{
"number": "1.2",
"title": "Delegation to QUIC",
"anchor": "delegation-to-quic"
}
]
},
{
"number": "2",
"title": "HTTP/3 Protocol Overview",
"anchor": "http3-protocol-overview",
"subsections": [
{
"number": "2.1",
"title": "Document Organization",
"anchor": "document-organization"
},
{
"number": "2.2",
"title": "Conventions and Terminology",
"anchor": "conventions-and-terminology"
}
]
},
{
"number": "3",
"title": "Connection Setup and Management",
"anchor": "connection-setup",
"subsections": [
{
"number": "3.1",
"title": "Discovering an HTTP/3 Endpoint",
"anchor": "discovery",
… (516 lines)structure-8446
Arguments: get_rfc_structure
json
{
"rfc": 8446
}Output (614 lines)
text
# structure-8446
tool: get_rfc_structure
args: {"rfc":8446}
--- json ---
{
"metadata": {
"title": "The Transport Layer Security (TLS) Protocol Version 1.3",
"number": 8446,
"date": "2018-08",
"category": "std",
"stream": "IETF",
"abstract": "This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.\n\n This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations."
},
"sections": [
{
"number": "1",
"title": "Introduction",
"subsections": [
{
"number": "1.1",
"title": "Conventions and Terminology"
},
{
"number": "1.2",
"title": "Major Differences from TLS 1.2"
},
{
"number": "1.3",
"title": "Updates Affecting TLS 1.2"
}
]
},
{
"number": "2",
"title": "Protocol Overview",
"subsections": [
{
"number": "2.1",
"title": "Incorrect DHE Share"
},
{
"number": "2.2",
"title": "Resumption and Pre-Shared Key (PSK)"
},
{
"number": "2.3",
"title": "0-RTT Data"
}
]
},
{
"number": "3",
"title": "Presentation Language",
"subsections": [
{
"number": "3.1",
"title": "Basic Block Size"
},
… (614 lines)structure-854
Arguments: get_rfc_structure
json
{
"rfc": 854
}Output (119 lines)
text
# structure-854
tool: get_rfc_structure
args: {"rfc":854}
--- json ---
{
"metadata": {
"title": "TELNET PROTOCOL SPECIFICATION",
"number": 854,
"date": "1983-05",
"category": "std",
"abstract": "This is the specification of the Telnet protocol used for remote terminal access in the ARPA Internet. The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication (\"linking\") and process-process communication (distributed computation). This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 18639."
},
"sections": [
{
"number": "1",
"title": "INTRODUCTION"
},
{
"number": "2",
"title": "GENERAL CONSIDERATIONS"
},
{
"number": "3",
"title": "THE NETWORK VIRTUAL TERMINAL",
"subsections": [
{
"number": "3.1",
"title": "TRANSMISSION OF DATA"
},
{
"number": "3.2",
"title": "STANDARD REPRESENTATION OF CONTROL FUNCTIONS",
"subsections": [
{
"number": "3.2.1",
"title": "Interrupt Process (IP)"
},
{
"number": "3.2.2",
"title": "Abort Output (AO)"
},
{
"number": "3.2.3",
"title": "Are You There (AYT)"
},
{
"number": "3.2.4",
"title": "Erase Character (EC)"
},
{
"number": "3.2.5",
"title": "Erase Line (EL)"
}
]
},
{
"number": "3.3",
"title": "THE TELNET \"SYNCH\" SIGNAL"
… (119 lines)structure-792
Arguments: get_rfc_structure
json
{
"rfc": 792
}Output (332 lines)
text
# structure-792
tool: get_rfc_structure
args: {"rfc":792}
--- json ---
{
"metadata": {
"title": "INTERNET CONTROL MESSAGE PROTOCOL",
"number": 792,
"date": "1981-09",
"category": "std"
},
"sections": [
{
"number": "1",
"title": "Introduction"
},
{
"number": "2",
"title": "Message Formats",
"subsections": [
{
"number": "2.1",
"title": "Version"
},
{
"number": "2.2",
"title": "IHL"
},
{
"number": "2.3",
"title": "Type of Service"
},
{
"number": "2.4",
"title": "Total Length"
},
{
"number": "2.5",
"title": "Identification, Flags, Fragment Offset"
},
{
"number": "2.6",
"title": "Time to Live"
},
{
"number": "2.7",
"title": "Protocol"
},
{
"number": "2.8",
"title": "Header Checksum"
},
{
"number": "2.9",
"title": "Source Address"
},
{
"number": "2.10",
… (332 lines)get_requirements
requirements-5652-1.2
Arguments: get_requirements
json
{
"rfc": 5652,
"section": "1.2"
}Output (20 lines)
text
# requirements-5652-1.2
tool: get_requirements
args: {"rfc":5652,"section":"1.2"}
--- json ---
{
"rfc": 5652,
"filter": {
"section": "1.2",
"level": "all"
},
"stats": {
"total": 0,
"byLevel": {}
},
"requirements": [],
"_source": "text",
"_sourceNote": "Warning: Parsed from text format. Requirement extraction accuracy may be limited."
}requirements-6455-5.2
Arguments: get_requirements
json
{
"rfc": 6455,
"section": "5.2"
}Output (108 lines)
text
# requirements-6455-5.2
tool: get_requirements
args: {"rfc":6455,"section":"5.2"}
--- json ---
{
"rfc": 6455,
"filter": {
"section": "5.2",
"level": "all"
},
"stats": {
"total": 8,
"byLevel": {
"MAY": 1,
"MUST": 7
}
},
"requirements": [
{
"id": "R-5.2-1",
"level": "MAY",
"text": "The first fragment MAY also be the final fragment.",
"section": "5.2",
"sectionTitle": "Base Framing Protocol",
"fullContext": "FIN: 1 bit Indicates that this is the final fragment in a message. The first fragment MAY also be the final fragment.",
"subject": "first fragment",
"action": "also be the final fragment"
},
{
"id": "R-5.2-2",
"level": "MUST",
"text": "RSV1, RSV2, RSV3: 1 bit each MUST be 0 unless an extension is negotiated that defines meanings for non-zero values.",
"section": "5.2",
"sectionTitle": "Base Framing Protocol",
"fullContext": "RSV1, RSV2, RSV3: 1 bit each MUST be 0 unless an extension is negotiated that defines meanings for non-zero values. If a nonzero value is received and none of the negotiated extensions defines the meaning of such a nonzero value, the receiving endpoint MUST _Fail the WebSocket Connection_.",
"subject": "bit",
"exception": "an extension is negotiated that defines meanings for non-zero values",
"action": "be 0 unless an extension is negotiated that defines meanings for non-zero values"
},
{
"id": "R-5.2-3",
"level": "MUST",
"text": "If a nonzero value is received and none of the negotiated extensions defines the meaning of such a nonzero value, the receiving endpoint MUST _Fail the WebSocket Connection_.",
"section": "5.2",
"sectionTitle": "Base Framing Protocol",
"fullContext": "RSV1, RSV2, RSV3: 1 bit each MUST be 0 unless an extension is negotiated that defines meanings for non-zero values. If a nonzero value is received and none of the negotiated extensions defines the meaning of such a nonzero value, the receiving endpoint MUST _Fail the WebSocket Connection_.",
"subject": "receiving endpoint",
"condition": "a nonzero value is received and none of the negotiated extensions defines the meaning of such a nonzero value",
"action": "_Fail the WebSocket Connection_"
},
{
"id": "R-5.2-4",
"level": "MUST",
"text": "If an unknown opcode is received, the receiving endpoint MUST _Fail the WebSocket Connection_.",
"section": "5.2",
"sectionTitle": "Base Framing Protocol",
"fullContext": "Opcode: 4 bits Defines the interpretation of the \"Payload data\". If an unknown opcode is received, the receiving endpoint MUST _Fail the WebSocket Connection_. The following values are defined.",
"subject": "receiving endpoint",
… (108 lines)requirements-1123-3.2
Arguments: get_requirements
json
{
"rfc": 1123,
"section": "3.2"
}Output (293 lines)
text
# requirements-1123-3.2
tool: get_requirements
args: {"rfc":1123,"section":"3.2"}
--- json ---
{
"rfc": 1123,
"filter": {
"section": "3.2",
"level": "all"
},
"stats": {
"total": 26,
"byLevel": {
"MUST": 15,
"SHOULD": 5,
"MAY": 3,
"SHOULD NOT": 1,
"MUST NOT": 2
}
},
"requirements": [
{
"id": "R-3.2.1-1",
"level": "MUST",
"text": "Every Telnet implementation MUST include option negotiation and subnegotiation machinery [TELNET:2].",
"section": "3.2.1",
"sectionTitle": "Option Negotiation: RFC-854, pp. 2-3",
"fullContext": "Every Telnet implementation MUST include option negotiation and subnegotiation machinery [TELNET:2].",
"subject": "telnet implementation",
"action": "include option negotiation and subnegotiation machinery [TELNET:2]"
},
{
"id": "R-3.2.1-2",
"level": "MUST",
"text": "A host MUST carefully follow the rules of RFC-854 to avoid option-negotiation loops.",
"section": "3.2.1",
"sectionTitle": "Option Negotiation: RFC-854, pp. 2-3",
"fullContext": "A host MUST carefully follow the rules of RFC-854 to avoid option-negotiation loops. A host MUST refuse (i.e, reply WONT/DONT to a DO/WILL) an unsupported option. Option negotiation SHOULD continue to function (even if all requests are refused) throughout the lifetime of a Telnet connection.",
"subject": "host",
"action": "carefully follow the rules of RFC-854 to avoid option-negotiation loops"
},
{
"id": "R-3.2.1-3",
"level": "MUST",
"text": "A host MUST refuse (i.e, reply WONT/DONT to a DO/WILL) an unsupported option.",
"section": "3.2.1",
"sectionTitle": "Option Negotiation: RFC-854, pp. 2-3",
"fullContext": "A host MUST carefully follow the rules of RFC-854 to avoid option-negotiation loops. A host MUST refuse (i.e, reply WONT/DONT to a DO/WILL) an unsupported option. Option negotiation SHOULD continue to function (even if all requests are refused) throughout the lifetime of a Telnet connection.",
"subject": "host",
"action": "refuse (i.e, reply WONT/DONT to a DO/WILL) an unsupported option"
},
{
"id": "R-3.2.1-4",
"level": "SHOULD",
"text": "Option negotiation SHOULD continue to function (even if all requests are refused) throughout the lifetime of a Telnet connection.",
"section": "3.2.1",
"sectionTitle": "Option Negotiation: RFC-854, pp. 2-3",
"fullContext": "A host MUST carefully follow the rules of RFC-854 to avoid option-negotiation loops. A host MUST refuse (i.e, reply WONT/DONT to a DO/WILL) an unsupported option. Option negotiation SHOULD continue to function (even if all requests are refused) throughout the lifetime of a Telnet connection.",
… (293 lines)requirements-6455-9.1
Arguments: get_requirements
json
{
"rfc": 6455,
"section": "9.1"
}Output (98 lines)
text
# requirements-6455-9.1
tool: get_requirements
args: {"rfc":6455,"section":"9.1"}
--- json ---
{
"rfc": 6455,
"filter": {
"section": "9.1",
"level": "all"
},
"stats": {
"total": 7,
"byLevel": {
"MUST": 4,
"MAY": 2,
"MUST NOT": 1
}
},
"requirements": [
{
"id": "R-9.1-1",
"level": "MUST",
"text": "If a value is received by either the client or the server during negotiation that does not conform to the ABNF below, the recipient of such malformed data MUST immediately _Fail the WebSocket Connection_.",
"section": "9.1",
"sectionTitle": "Negotiating Extensions",
"fullContext": "A client requests extensions by including a |Sec-WebSocket- Extensions| header field, which follows the normal rules for HTTP header fields (see [RFC2616], Section 4.2) and the value of the header field is defined by the following ABNF [RFC2616]. Note that this section is using ABNF syntax/rules from [RFC2616], including the \"implied *LWS rule\". If a value is received by either the client or the server during negotiation that does not conform to the ABNF below, the recipient of such malformed data MUST immediately _Fail the WebSocket Connection_.",
"subject": "malformed data",
"condition": "a value is received by either the client or the server during negotiation that does not conform to the ABNF below",
"action": "immediately _Fail the WebSocket Connection_"
},
{
"id": "R-9.1-2",
"level": "MUST",
"text": "When using the quoted-string syntax variant, the value after quoted-string unescaping MUST conform to the 'token' ABNF.",
"section": "9.1",
"sectionTitle": "Negotiating Extensions",
"fullContext": "Sec-WebSocket-Extensions = extension-list extension-list = 1#extension extension = extension-token *( \";\" extension-param ) extension-token = registered-token registered-token = token extension-param = token [ \"=\" (token | quoted-string) ] ;When using the quoted-string syntax variant, the value ;after quoted-string unescaping MUST conform to the ;'token' ABNF.",
"subject": "quoted-string unescaping",
"condition": "using the quoted-string syntax variant",
"action": "conform to the 'token' ABNF"
},
{
"id": "R-9.1-3",
"level": "MAY",
"text": "Note that like other HTTP header fields, this header field MAY be split or combined across multiple lines.",
"section": "9.1",
"sectionTitle": "Negotiating Extensions",
"fullContext": "Note that like other HTTP header fields, this header field MAY be split or combined across multiple lines. Ergo, the following are equivalent:",
"subject": "header field",
"action": "be split or combined across multiple lines"
},
{
"id": "R-9.1-4",
"level": "MUST",
"text": "Any extension-token used MUST be a registered token (see Section 11.4).",
"section": "9.1",
"sectionTitle": "Negotiating Extensions",
"fullContext": "Any extension-token used MUST be a registered token (see Section 11.4). The parameters supplied with any given extension MUST be defined for that extension. Note that the client is only offering to use any advertised extensions and MUST NOT use them unless the server indicates that it wishes to use the extension.",
… (98 lines)requirements-9051-2.3.1.1
Arguments: get_requirements
json
{
"rfc": 9051,
"section": "2.3.1.1"
}Output (163 lines)
text
# requirements-9051-2.3.1.1
tool: get_requirements
args: {"rfc":9051,"section":"2.3.1.1"}
--- json ---
{
"rfc": 9051,
"filter": {
"section": "2.3.1.1",
"level": "all"
},
"stats": {
"total": 13,
"byLevel": {
"MUST NOT": 4,
"SHOULD NOT": 1,
"MUST": 7,
"SHOULD": 1
}
},
"requirements": [
{
"id": "R-2.3.1.1-1",
"level": "MUST NOT",
"text": "A UID is an unsigned non-zero 32-bit value assigned to each message, which when used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever.",
"section": "2.3.1.1",
"sectionTitle": "Unique Identifier (UID) Message Attribute",
"fullContext": "A UID is an unsigned non-zero 32-bit value assigned to each message, which when used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever. Unique identifiers are assigned in a strictly ascending fashion in the mailbox; as each message is added to the mailbox, it is assigned a higher UID than those of all message(s) that are already in the mailbox. Unlike message sequence numbers, unique identifiers are not necessarily contiguous.",
"subject": "value",
"condition": "used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever",
"action": "refer to any other message in the mailbox or any subsequent mailbox with the same name forever"
},
{
"id": "R-2.3.1.1-2",
"level": "MUST NOT",
"text": "The unique identifier of a message MUST NOT change during the session and SHOULD NOT change between sessions.",
"section": "2.3.1.1",
"sectionTitle": "Unique Identifier (UID) Message Attribute",
"fullContext": "The unique identifier of a message MUST NOT change during the session and SHOULD NOT change between sessions. Any change of unique identifiers between sessions MUST be detectable using the UIDVALIDITY mechanism discussed below. Persistent unique identifiers are required for a client to resynchronize its state from a previous session with the server (e.g., disconnected or offline access clients [IMAP-MODEL]); this is discussed further in [IMAP-DISC].",
"subject": "message",
"action": "change during the session and SHOULD NOT change between sessions"
},
{
"id": "R-2.3.1.1-3",
"level": "SHOULD NOT",
"text": "The unique identifier of a message MUST NOT change during the session and SHOULD NOT change between sessions.",
"section": "2.3.1.1",
"sectionTitle": "Unique Identifier (UID) Message Attribute",
"fullContext": "The unique identifier of a message MUST NOT change during the session and SHOULD NOT change between sessions. Any change of unique identifiers between sessions MUST be detectable using the UIDVALIDITY mechanism discussed below. Persistent unique identifiers are required for a client to resynchronize its state from a previous session with the server (e.g., disconnected or offline access clients [IMAP-MODEL]); this is discussed further in [IMAP-DISC].",
"subject": "message",
"action": "change between sessions"
},
{
"id": "R-2.3.1.1-4",
"level": "MUST",
"text": "Any change of unique identifiers between sessions MUST be detectable using the UIDVALIDITY mechanism discussed below.",
"section": "2.3.1.1",
"sectionTitle": "Unique Identifier (UID) Message Attribute",
"fullContext": "The unique identifier of a message MUST NOT change during the session and SHOULD NOT change between sessions. Any change of unique identifiers between sessions MUST be detectable using the UIDVALIDITY mechanism discussed below. Persistent unique identifiers are required for a client to resynchronize its state from a previous session with the server (e.g., disconnected or offline access clients [IMAP-MODEL]); this is discussed further in [IMAP-DISC].",
… (163 lines)requirements-9110-9.3.5
Arguments: get_requirements
json
{
"rfc": 9110,
"section": "9.3.5"
}Output (55 lines)
text
# requirements-9110-9.3.5
tool: get_requirements
args: {"rfc":9110,"section":"9.3.5"}
--- json ---
{
"rfc": 9110,
"filter": {
"section": "9.3.5",
"level": "all"
},
"stats": {
"total": 3,
"byLevel": {
"SHOULD": 1,
"SHOULD NOT": 2
}
},
"requirements": [
{
"id": "R-9.3.5-1",
"level": "SHOULD",
"text": "If a DELETE method is successfully applied, the origin server SHOULD send a 202 (Accepted) status code if the action will likely succeed but has not yet been enacted, a 204 (No Content) status code if the action has been enacted and no further information is to be supplied, or a 200 (OK) status code if the action has been enacted and the response message includes a representation describing the status.",
"section": "9.3.5",
"sectionTitle": "DELETE",
"fullContext": "If a DELETE method is successfully applied, the origin server SHOULD send a 202 (Accepted) status code if the action will likely succeed but has not yet been enacted, a 204 (No Content) status code if the action has been enacted and no further information is to be supplied, or a 200 (OK) status code if the action has been enacted and the response message includes a representation describing the status.",
"subject": "origin server",
"condition": "a DELETE method is successfully applied",
"action": "send a 202 (Accepted) status code if the action will likely succeed but has not yet been enacted"
},
{
"id": "R-9.3.5-2",
"level": "SHOULD NOT",
"text": "A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.",
"section": "9.3.5",
"sectionTitle": "DELETE",
"fullContext": "Although request message framing is independent of the method used, content received in a DELETE request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.",
"subject": "client",
"exception": "it is made directly to an origin server that has previously indicated",
"action": "generate content in a DELETE request unless it is made directly to an origin server that has previously indicated"
},
{
"id": "R-9.3.5-3",
"level": "SHOULD NOT",
"text": "An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.",
"section": "9.3.5",
"sectionTitle": "DELETE",
"fullContext": "Although request message framing is independent of the method used, content received in a DELETE request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.",
"subject": "origin server",
"action": "rely on private agreements to receive content"
}
],
"_source": "xml"
}requirements-9110-10.1.1
Arguments: get_requirements
json
{
"rfc": 9110,
"section": "10.1.1"
}Output (172 lines)
text
# requirements-9110-10.1.1
tool: get_requirements
args: {"rfc":9110,"section":"10.1.1"}
--- json ---
{
"rfc": 9110,
"filter": {
"section": "10.1.1",
"level": "all"
},
"stats": {
"total": 14,
"byLevel": {
"MAY": 4,
"MUST NOT": 2,
"MUST": 5,
"SHOULD NOT": 1,
"SHOULD": 2
}
},
"requirements": [
{
"id": "R-10.1.1-1",
"level": "MAY",
"text": "A server that receives an Expect field value containing a member other than 100-continue MAY respond with a 417 (Expectation Failed) status code to indicate that the unexpected expectation cannot be met.",
"section": "10.1.1",
"sectionTitle": "Expect",
"fullContext": "A server that receives an Expect field value containing a member other than 100-continue MAY respond with a 417 (Expectation Failed) status code to indicate that the unexpected expectation cannot be met.",
"subject": "continue",
"action": "respond with a 417 (Expectation Failed) status code to indicate that the unexpected expectation cannot be met"
},
{
"id": "R-10.1.1-2",
"level": "MUST NOT",
"text": "A client MUST NOT generate a 100-continue expectation in a request that does not include content.",
"section": "10.1.1",
"sectionTitle": "Expect",
"fullContext": "A client MUST NOT generate a 100-continue expectation in a request that does not include content.",
"subject": "client",
"action": "generate a 100-continue expectation in a request that does not include content"
},
{
"id": "R-10.1.1-3",
"level": "MUST",
"text": "A client that will wait for a 100 (Continue) response before sending the request content MUST send an Expect header field containing a 100-continue expectation.",
"section": "10.1.1",
"sectionTitle": "Expect",
"fullContext": "A client that will wait for a 100 (Continue) response before sending the request content MUST send an Expect header field containing a 100-continue expectation.",
"subject": "request content",
"action": "send an Expect header field containing a 100-continue expectation"
},
{
"id": "R-10.1.1-4",
"level": "MAY",
"text": "A client that sends a 100-continue expectation is not required to wait for any specific length of time; such a client MAY proceed to send the content even if it has not yet received a response.",
"section": "10.1.1",
"sectionTitle": "Expect",
"fullContext": "A client that sends a 100-continue expectation is not required to wait for any specific length of time; such a client MAY proceed to send the content even if it has not yet received a response. Furthermore, since 100 (Continue) responses cannot be sent through an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an indefinite period before sending the content.",
… (172 lines)get_definitions
definitions-9110-cache
Arguments: get_definitions
json
{
"rfc": 9110,
"term": "cache"
}Output (49 lines)
text
# definitions-9110-cache
tool: get_definitions
args: {"rfc":9110,"term":"cache"}
--- json ---
{
"rfc": 9110,
"searchTerm": "cache",
"count": 7,
"definitions": [
{
"term": "cache",
"definition": "A \"cache\" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server MAY employ a cache, though a cache cannot be used while acting as a tunnel.",
"section": "3.8"
},
{
"term": "cacheable",
"definition": "A response is \"cacheable\" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in [CACHING].",
"section": "3.8"
},
{
"term": "non-transforming proxy",
"definition": "Some intermediaries include features for transforming messages and their content. A proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link. However, operational problems might occur when these transformations are applied to content intended for critical applications, such as medical imaging or scientific data analysis, particularly when integrity checks or digital signatures are used to ensure that the content received is identical to the original.",
"section": "7.7"
},
{
"term": "Authorization header field",
"definition": "A proxy forwarding a request MUST NOT modify any Authorization header fields in that request. See Section 3.5 of [CACHING] for details of and requirements pertaining to handling of the Authorization header field by HTTP caches.",
"section": "11.6.2"
},
{
"term": "If-None-Match header field",
"definition": "If-None-Match is primarily used in conditional GET requests to enable efficient updates of cached information with a minimum amount of transaction overhead. When a client desires to update one or more stored responses that have entity tags, the client SHOULD generate an If-None-Match header field containing a list of those entity tags when making a GET request; this allows recipient servers to send a 304 (Not Modified) response to indicate when one of those stored responses matches the selected representation.",
"section": "13.1.2"
},
{
"term": "Range header field",
"definition": "A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since they support efficient recovery from partially failed transfers and partial retrieval of large representations.",
"section": "14.2"
},
{
"term": "203 Non-Authoritative Information (status code)",
"definition": "The 203 (Non-Authoritative Information) status code indicates that the request was successful but the enclosed content has been modified from that of the origin server's 200 (OK) response by a transforming proxy (Section 7.7). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might impact later decisions regarding the content. For example, future cache validation requests for the content might only be applicable along the same request path (through the same proxies).",
"section": "15.3.4"
}
],
"_source": "xml"
}definitions-9111-cache-directive
Arguments: get_definitions
json
{
"rfc": 9111,
"term": "max-age"
}Output (24 lines)
text
# definitions-9111-cache-directive
tool: get_definitions
args: {"rfc":9111,"term":"max-age"}
--- json ---
{
"rfc": 9111,
"searchTerm": "max-age",
"count": 2,
"definitions": [
{
"term": "max-age (cache directive)",
"definition": "The max-age request directive indicates that the client prefers a response whose age is less than or equal to the specified number of seconds. Unless the max-stale request directive is also present, the client does not wish to receive a stale response.",
"section": "5.2.1.1"
},
{
"term": "s-maxage (cache directive)",
"definition": "The s-maxage response directive indicates that, for a shared cache, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field.",
"section": "5.2.2.10"
}
],
"_source": "xml"
}definitions-9110-client
Arguments: get_definitions
json
{
"rfc": 9110,
"term": "client"
}Output (234 lines)
text
# definitions-9110-client
tool: get_definitions
args: {"rfc":9110,"term":"client"}
--- json ---
{
"rfc": 9110,
"searchTerm": "client",
"count": 44,
"definitions": [
{
"term": "client",
"definition": "An HTTP \"client\" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP \"server\" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.",
"section": "3.3"
},
{
"term": "server",
"definition": "An HTTP \"client\" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP \"server\" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.",
"section": "3.3"
},
{
"term": "connection",
"definition": "HTTP is a client/server protocol that operates over a reliable transport- or session-layer \"connection\".",
"section": "3.3"
},
{
"term": "user agent",
"definition": "The term \"user agent\" refers to any of the various client programs that initiate a request.",
"section": "3.5"
},
{
"term": "proxy",
"definition": "A \"proxy\" is a message-forwarding agent that is chosen by the client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations are minimal, such as for proxy requests for \"http\" URIs, whereas other requests might require translation to and from entirely different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary for the sake of security services, annotation services, or shared caching. Some proxies are designed to apply transformations to selected messages or content while they are being forwarded, as described in Section 7.7.",
"section": "3.7"
},
{
"term": "interception proxy",
"definition": "For example, an \"interception proxy\" [RFC3040] (also commonly known as a \"transparent proxy\" [RFC1919]) differs from an HTTP proxy because it is not chosen by the client. Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate firewalls to enforce network usage policies.",
"section": "3.7"
},
{
"term": "transparent proxy",
"definition": "For example, an \"interception proxy\" [RFC3040] (also commonly known as a \"transparent proxy\" [RFC1919]) differs from an HTTP proxy because it is not chosen by the client. Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate firewalls to enforce network usage policies.",
"section": "3.7"
},
{
"term": "cache",
"definition": "A \"cache\" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server MAY employ a cache, though a cache cannot be used while acting as a tunnel.",
"section": "3.8"
},
{
"term": "cacheable",
"definition": "A response is \"cacheable\" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in [CACHING].",
"section": "3.8"
},
{
"term": "https URI scheme",
"definition": "The \"https\" URI scheme is hereby defined for minting identifiers within the hierarchical namespace governed by a potential origin server listening for TCP connections on a given port and capable of establishing a TLS ([TLS13]) connection that has been secured for HTTP communication. In this context, \"secured\" specifically means that the server has been authenticated as acting on behalf of the identified authority and all HTTP communication with that server has confidentiality and integrity protection that is acceptable to both client and server.",
"section": "4.2.2"
… (234 lines)definitions-9114
Arguments: get_definitions
json
{
"rfc": 9114
}Output (468 lines)
text
# definitions-9114
tool: get_definitions
args: {"rfc":9114}
--- json ---
{
"rfc": 9114,
"count": 91,
"definitions": [
{
"term": "abort",
"definition": "An abrupt termination of a connection or stream, possibly due to an error condition.",
"section": "2.2"
},
{
"term": "client",
"definition": "The endpoint that initiates an HTTP/3 connection. Clients send HTTP requests and receive HTTP responses.",
"section": "2.2"
},
{
"term": "connection",
"definition": "A transport-layer connection between two endpoints using QUIC as the transport protocol.",
"section": "2.2"
},
{
"term": "connection error",
"definition": "An error that affects the entire HTTP/3 connection.",
"section": "2.2"
},
{
"term": "endpoint",
"definition": "Either the client or server of the connection.",
"section": "2.2"
},
{
"term": "frame",
"definition": "The smallest unit of communication on a stream in HTTP/3, consisting of a header and a variable-length sequence of bytes structured according to the frame type. Protocol elements called \"frames\" exist in both this document and [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are referenced, the frame name will be prefaced with \"QUIC\". For example, \"QUIC CONNECTION_CLOSE frames\". References without this preface refer to frames defined in Section 7.2.",
"section": "2.2"
},
{
"term": "HTTP/3 connection",
"definition": "A QUIC connection where the negotiated application protocol is HTTP/3.",
"section": "2.2"
},
{
"term": "peer",
"definition": "An endpoint. When discussing a particular endpoint, \"peer\" refers to the endpoint that is remote to the primary subject of discussion.",
"section": "2.2"
},
{
"term": "receiver",
"definition": "An endpoint that is receiving frames.",
"section": "2.2"
},
{
"term": "sender",
"definition": "An endpoint that is transmitting frames.",
"section": "2.2"
},
… (468 lines)definitions-5280
Arguments: get_definitions
json
{
"rfc": 5280
}Output (29 lines)
text
# definitions-5280
tool: get_definitions
args: {"rfc":5280}
--- json ---
{
"rfc": 5280,
"count": 3,
"definitions": [
{
"term": "CA",
"definition": "certification authority;",
"section": "3"
},
{
"term": "RA",
"definition": "registration authority, i.e., an optional system to which",
"section": "3"
},
{
"term": "CRL issuer",
"definition": "a system that generates and signs CRLs; and",
"section": "3"
}
],
"_source": "text",
"_sourceNote": "Warning: Parsed from text format. Definition extraction accuracy may be limited."
}definitions-7519
Arguments: get_definitions
json
{
"rfc": 7519
}Output (64 lines)
text
# definitions-7519
tool: get_definitions
args: {"rfc":7519}
--- json ---
{
"rfc": 7519,
"count": 10,
"definitions": [
{
"term": "JSON Web Token (JWT)",
"definition": "A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the claims to be digitally signed or MACed and/or encrypted.",
"section": "2"
},
{
"term": "JWT Claims Set",
"definition": "A JSON object that contains the claims conveyed by the JWT.",
"section": "2"
},
{
"term": "Claim",
"definition": "A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value.",
"section": "2"
},
{
"term": "Claim Name",
"definition": "The name portion of a claim representation. A Claim Name is always a string.",
"section": "2"
},
{
"term": "Claim Value",
"definition": "The value portion of a claim representation. A Claim Value can be any JSON value.",
"section": "2"
},
{
"term": "Nested JWT",
"definition": "A JWT in which nested signing and/or encryption are employed. In Nested JWTs, a JWT is used as the payload or plaintext value of an enclosing JWS or JWE structure, respectively.",
"section": "2"
},
{
"term": "Unsecured JWT",
"definition": "A JWT whose claims are not integrity protected or encrypted.",
"section": "2"
},
{
"term": "Collision-Resistant Name",
"definition": "A name in a namespace that enables names to be allocated in a manner such that they are highly unlikely to collide with other names. Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion…",
"section": "2"
},
{
"term": "StringOrURI",
"definition": "A JSON string value, with the additional requirement that while arbitrary string values MAY be used, any value containing a \":\" character MUST be a URI [RFC3986]. StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied.",
"section": "2"
},
{
"term": "NumericDate",
"definition": "A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the IEEE Std 1003.1, 2013 Edition [POSIX.1] definition \"Seconds Since the Epoch\", in which each day is accounted for by exactly 86400 seconds, other than that non-integer values can be represented. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.",
"section": "2"
}
… (64 lines)get_rfc_dependencies
dependencies-6455
Arguments: get_rfc_dependencies
json
{
"rfc": 6455
}Output (144 lines)
text
# dependencies-6455
tool: get_rfc_dependencies
args: {"rfc":6455}
--- json ---
{
"rfc": 6455,
"normative": [
{
"title": "Coded Character Set - 7-bit American Standard Code for Information Interchange",
"anchor": "ANSI.X3-4.1986"
},
{
"title": "Secure Hash Standard",
"anchor": "FIPS.180-3"
},
{
"rfcNumber": 1928,
"title": "SOCKS Protocol Version 5",
"anchor": "RFC1928"
},
{
"rfcNumber": 2119,
"title": "Key words for use in RFCs to Indicate Requirement Levels",
"anchor": "RFC2119"
},
{
"rfcNumber": 2616,
"title": "Hypertext Transfer Protocol -- HTTP/1.1",
"anchor": "RFC2616"
},
{
"rfcNumber": 2817,
"title": "Upgrading to TLS Within HTTP/1.1",
"anchor": "RFC2817"
},
{
"rfcNumber": 2818,
"title": "HTTP Over TLS",
"anchor": "RFC2818"
},
{
"rfcNumber": 3629,
"title": "UTF-8, a transformation format of ISO 10646",
"anchor": "RFC3629"
},
{
"rfcNumber": 3864,
"title": "Registration Procedures for Message Header Fields",
"anchor": "RFC3864"
},
{
"rfcNumber": 3986,
"title": "Uniform Resource Identifier (URI): Generic Syntax",
"anchor": "RFC3986"
},
{
"rfcNumber": 3987,
"title": "Internationalized Resource Identifiers (IRIs)",
… (144 lines)dependencies-1123
Arguments: get_rfc_dependencies
json
{
"rfc": 1123
}Output (282 lines)
text
# dependencies-1123
tool: get_rfc_dependencies
args: {"rfc":1123}
--- json ---
{
"rfc": 1123,
"normative": [],
"informative": [
{
"rfcNumber": 1122,
"title": "Requirements for Internet Hosts -- Communication Layers",
"anchor": "INTRO:1"
},
{
"title": "DDN Protocol Handbook",
"anchor": "INTRO:2"
},
{
"rfcNumber": 1011,
"title": "Official Internet Protocols",
"anchor": "INTRO:3"
},
{
"rfcNumber": 980,
"title": "Protocol Document Order Information",
"anchor": "INTRO:4"
},
{
"rfcNumber": 1010,
"title": "Assigned Numbers",
"anchor": "INTRO:5"
},
{
"rfcNumber": 854,
"title": "Telnet Protocol Specification",
"anchor": "TELNET:1"
},
{
"rfcNumber": 855,
"title": "Telnet Option Specification",
"anchor": "TELNET:2"
},
{
"rfcNumber": 856,
"title": "Telnet Binary Transmission",
"anchor": "TELNET:3"
},
{
"rfcNumber": 857,
"title": "Telnet Echo Option",
"anchor": "TELNET:4"
},
{
"rfcNumber": 858,
"title": "Telnet Suppress Go Ahead Option",
"anchor": "TELNET:5"
},
{
… (282 lines)dependencies-1305
Arguments: get_rfc_dependencies
json
{
"rfc": 1305
}Output (220 lines)
text
# dependencies-1305
tool: get_rfc_dependencies
args: {"rfc":1305}
--- json ---
{
"rfc": 1305,
"normative": [],
"informative": [
{
"title": "AT&T's new approach to the synchronization of telecommunication networks",
"anchor": "ABA89"
},
{
"title": "National Bureau of Standards Monograph 140, U.S",
"anchor": "ALL74a"
},
{
"title": "The National Bureau of Standards atomic time scale: generation, stability, accuracy and accessibility",
"anchor": "ALL74b"
},
{
"title": "Digital Synchronization Network Plan",
"anchor": "BEL86"
},
{
"title": "Bertsekas, D., and R",
"anchor": "BER87"
},
{
"title": "Time and frequency dissemination: an overview of principles and techniques",
"anchor": "BLA74"
},
{
"title": "Short term frequency effects in networks of coupled oscillators",
"anchor": "BRA80"
},
{
"title": "An experiment in clock synchronisation",
"anchor": "COL88"
},
{
"rfcNumber": 791,
"title": "Defense Advanced Research Projects Agency",
"anchor": "DAR81a"
},
{
"rfcNumber": 792,
"title": "Defense Advanced Research Projects Agency",
"anchor": "DAR81b"
},
{
"title": "Digital Time Service Functional Specification Version T.1.0.5",
"anchor": "DEC89"
},
{
"title": "Calendrical Calculations",
"anchor": "DER90"
},
… (220 lines)get_related_sections
related-6749-3.1
Arguments: get_related_sections
json
{
"rfc": 6749,
"section": "3.1"
}Output (19 lines)
text
# related-6749-3.1
tool: get_related_sections
args: {"rfc":6749,"section":"3.1"}
--- json ---
{
"rfc": 6749,
"section": "3.1",
"title": "Authorization Endpoint",
"relatedSections": [
{
"number": "1.6",
"title": "TLS Version"
}
],
"_source": "text",
"_sourceNote": "Warning: Parsed from text format. Related section accuracy may be limited."
}generate_checklist
checklist-9110-9.3.5
Arguments: generate_checklist
json
{
"rfc": 9110,
"sections": [
"9.3.5"
]
}Output (30 lines)
text
# checklist-9110-9.3.5
tool: generate_checklist
args: {"rfc":9110,"sections":["9.3.5"]}
--- markdown ---
# RFC 9110 Implementation Checklist
**HTTP Semantics**
Generated: <generatedAt>
## Recommended Requirements (SHOULD / RECOMMENDED)
- [ ] **SHOULD** If a DELETE method is successfully applied, the origin server SHOULD send a 202 (Accepted) status code if the action will likely succeed but has not yet been enacted, a 204 (No Content) status code if the action has been enacted and no further information is to be supplied, or a 200 (OK) status code if the action has been enacted and the response message includes a representation describing the status. (§9.3.5)
- [ ] **SHOULD NOT** A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. (§9.3.5)
- [ ] **SHOULD NOT** An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain. (§9.3.5)
--- json ---
{
"rfc": 9110,
"role": "both",
"stats": {
"must": 0,
"should": 3,
"may": 0,
"total": 3
},
"_source": "xml"
}checklist-6455-4.1
Arguments: generate_checklist
json
{
"rfc": 6455,
"sections": [
"4.1"
],
"role": "client"
}Output (79 lines)
text
# checklist-6455-4.1
tool: generate_checklist
args: {"rfc":6455,"sections":["4.1"],"role":"client"}
--- markdown ---
# RFC 6455 Implementation Checklist
**The WebSocket Protocol**
Role: client
Generated: <generatedAt>
## Mandatory Requirements (MUST / REQUIRED / SHALL)
- [ ] **MUST** When the client is to _Establish a WebSocket Connection_ given a set of (/host/, /port/, /resource name/, and /secure/ flag), along with a list of /protocols/ and /extensions/ to be used, and an /origin/ in the case of web browsers, it MUST open a connection, send an opening handshake, and read the server's handshake in response. (§4.1)
- [ ] **MUST** The components of the WebSocket URI passed into this algorithm (/host/, /port/, /resource name/, and /secure/ flag) MUST be valid according to the specification of WebSocket URIs specified in Section 3. (§4.1)
- [ ] **MUST** If any of the components are invalid, the client MUST _Fail the WebSocket Connection_ and abort these steps. (§4.1)
- [ ] **MUST** If the client already has a WebSocket connection to the remote host (IP address) identified by /host/ and port /port/ pair, even if the remote host is known by another name, the client MUST wait until that connection has been established or for that connection to have failed. (§4.1)
- [ ] **MUST** There MUST be no more than one connection in a CONNECTING state. (§4.1)
- [ ] **MUST** If multiple connections to the same IP address are attempted simultaneously, the client MUST serialize them so that there is no more than one connection at a time running through the following steps. (§4.1)
- [ ] **MUST** If the client cannot determine the IP address of the remote host (for example, because all communication is being done through a proxy server that performs DNS queries itself), then the client MUST assume for the purposes of this step that each host name refers to a distinct remote host, and instead the client SHOULD limit the total number of simultaneous pending connections to a reasonably low number (e.g., the client might allow simultaneous pending connections to a.example.com and b.example.com, but if thirty simultaneous connections to a single host are requested, that may not be allowed). (§4.1)
- [ ] **MUST** For the purpose of proxy autoconfiguration scripts, the URI to pass the function MUST be constructed from /host/, /port/, /resource name/, and the /secure/ flag using the definition of a WebSocket URI as given in Section 3. (§4.1)
- [ ] **MUST** If the connection could not be opened, either because a direct connection failed or because any proxy used returned an error, then the client MUST _Fail the WebSocket Connection_ and abort the connection attempt. (§4.1)
- [ ] **MUST** If /secure/ is true, the client MUST perform a TLS handshake over the connection after opening the connection and before sending the handshake data [RFC2818]. (§4.1)
- [ ] **MUST** If this fails (e.g., the server's certificate could not be verified), then the client MUST _Fail the WebSocket Connection_ and abort the connection. (§4.1)
- [ ] **MUST** If this fails (e.g., the server's certificate could not be verified), then the client MUST _Fail the WebSocket Connection_ and abort the connection. Otherwise, all further communication on this channel MUST run through the encrypted tunnel [RFC5246]. (§4.1)
- [ ] **MUST** Clients MUST use the Server Name Indication extension in the TLS handshake [RFC6066]. (§4.1)
- [ ] **MUST** Once a connection to the server has been established (including a connection via a proxy or over a TLS-encrypted tunnel), the client MUST send an opening handshake to the server. (§4.1)
- [ ] **MUST** The handshake MUST be a valid HTTP request as specified by [RFC2616]. (§4.1)
- [ ] **MUST** The method of the request MUST be GET, and the HTTP version MUST be at least 1.1. (§4.1)
- [ ] **MUST** The "Request-URI" part of the request MUST match the /resource name/ defined in Section 3 (a relative URI) or be an absolute http/https URI that, when parsed, has a /resource name/, /host/, and /port/ that match the corresponding ws/wss URI. (§4.1)
- [ ] **MUST** The request MUST contain a |Host| header field whose value contains /host/ plus optionally ":" followed by /port/ (when not using the default port). (§4.1)
- [ ] **MUST** The request MUST contain an |Upgrade| header field whose value MUST include the "websocket" keyword. (§4.1)
- [ ] **MUST** The request MUST contain a |Connection| header field whose value MUST include the "Upgrade" token. (§4.1)
- [ ] **MUST** The request MUST include a header field with the name |Sec-WebSocket-Key|. (§4.1)
- [ ] **MUST** The request MUST include a header field with the name |Sec-WebSocket-Key|. The value of this header field MUST be a nonce consisting of a randomly selected 16-byte value that has been base64-encoded (see Section 4 of [RFC4648]). (§4.1)
- [ ] **MUST** The nonce MUST be selected randomly for each connection. (§4.1)
- [ ] **MUST** The request MUST include a header field with the name |Origin| [RFC6454] if the request is coming from a browser client. (§4.1)
- [ ] **MUST** The request MUST include a header field with the name |Sec-WebSocket-Version|. (§4.1)
- [ ] **MUST** The request MUST include a header field with the name |Sec-WebSocket-Version|. The value of this header field MUST be 13. (§4.1)
- [ ] **MUST** If present, this value indicates one or more comma-separated subprotocol the client wishes to speak, ordered by preference. The elements that comprise this value MUST be non-empty strings with characters in the range U+0021 to U+007E not including separator characters as defined in [RFC2616] and MUST all be unique strings. (§4.1)
- [ ] **MUST** Once the client's opening handshake has been sent, the client MUST wait for a response from the server before sending any further data. (§4.1)
- [ ] **MUST** The client MUST validate the server's response as follows: (§4.1)
- [ ] **MUST** If the response lacks an |Upgrade| header field or the |Upgrade| header field contains a value that is not an ASCII case- insensitive match for the value "websocket", the client MUST _Fail the WebSocket Connection_. (§4.1)
- [ ] **MUST** If the response lacks a |Connection| header field or the |Connection| header field doesn't contain a token that is an ASCII case-insensitive match for the value "Upgrade", the client MUST _Fail the WebSocket Connection_. (§4.1)
- [ ] **MUST** If the response lacks a |Sec-WebSocket-Accept| header field or the |Sec-WebSocket-Accept| contains a value other than the base64-encoded SHA-1 of the concatenation of the |Sec-WebSocket- Key| (as a string, not base64-decoded) with the string "258EAFA5- E914-47DA-95CA-C5AB0DC85B11" but ignoring any leading and trailing whitespace, the client MUST _Fail the WebSocket Connection_. (§4.1)
- [ ] **MUST** If the response includes a |Sec-WebSocket-Extensions| header field and this header field indicates the use of an extension that was not present in the client's handshake (the server has indicated an extension not requested by the client), the client MUST _Fail the WebSocket Connection_. (§4.1)
- [ ] **MUST** If the response includes a |Sec-WebSocket-Protocol| header field and this header field indicates the use of a subprotocol that was not present in the client's handshake (the server has indicated a subprotocol not requested by the client), the client MUST _Fail the WebSocket Connection_. (§4.1)
- [ ] **MUST** If the server's response does not conform to the requirements for the server's handshake as defined in this section and in Section 4.2.2, the client MUST _Fail the WebSocket Connection_. (§4.1)
## Recommended Requirements (SHOULD / RECOMMENDED)
- [ ] **SHOULD** If the client cannot determine the IP address of the remote host (for example, because all communication is being done through a proxy server that performs DNS queries itself), then the client MUST assume for the purposes of this step that each host name refers to a distinct remote host, and instead the client SHOULD limit the total number of simultaneous pending connections to a reasonably low number (e.g., the client might allow simultaneous pending connections to a.example.com and b.example.com, but if thirty simultaneous connections to a single host are requested, that may not be allowed). (§4.1)
- [ ] **SHOULD** _Proxy Usage_: If the client is configured to use a proxy when using the WebSocket Protocol to connect to host /host/ and port /port/, then the client SHOULD connect to that proxy and ask it to open a TCP connection to the host given by /host/ and the port given by /port/. (§4.1)
- [ ] **SHOULD** If the client is not configured to use a proxy, then a direct TCP connection SHOULD be opened to the host given by /host/ and the port given by /port/. (§4.1)
## Optional Requirements (MAY / OPTIONAL)
… (79 lines)checklist-6455-client
Arguments: generate_checklist
json
{
"rfc": 6455,
"sections": [
"5.1",
"5.2",
"5.3"
],
"role": "client"
}Output (49 lines)
text
# checklist-6455-client
tool: generate_checklist
args: {"rfc":6455,"sections":["5.1","5.2","5.3"],"role":"client"}
--- markdown ---
# RFC 6455 Implementation Checklist
**The WebSocket Protocol**
Role: client
Generated: <generatedAt>
## Mandatory Requirements (MUST / REQUIRED / SHALL)
- [ ] **MUST** To avoid confusing network intermediaries (such as intercepting proxies) and for security reasons that are further discussed in Section 10.3, a client MUST mask all frames that it sends to the server (see Section 5.3 for further details). (§5.1)
- [ ] **MUST** A client MUST close a connection if it detects a masked frame. (§5.1)
- [ ] **MUST** RSV1, RSV2, RSV3: 1 bit each MUST be 0 unless an extension is negotiated that defines meanings for non-zero values. (§5.2)
- [ ] **MUST** If a nonzero value is received and none of the negotiated extensions defines the meaning of such a nonzero value, the receiving endpoint MUST _Fail the WebSocket Connection_. (§5.2)
- [ ] **MUST** If an unknown opcode is received, the receiving endpoint MUST _Fail the WebSocket Connection_. (§5.2)
- [ ] **MUST** If 127, the following 8 bytes interpreted as a 64-bit unsigned integer (the most significant bit MUST be 0) are the payload length. (§5.2)
- [ ] **MUST** Note that in all cases, the minimal number of bytes MUST be used to encode the length, for example, the length of a 124-byte-long string can't be encoded as the sequence 126, 0, 124. (§5.2)
- [ ] **MUST** Any extension MUST specify the length of the "Extension data", or how that length may be calculated, and how the extension use MUST be negotiated during the opening handshake. (§5.2)
- [ ] **MUST** 1 bit in length, MUST be 0 unless negotiated otherwise (§5.2)
- [ ] **MUST** A masked frame MUST have the field frame-masked set to 1, as defined in Section 5.2. (§5.3)
- [ ] **MUST** When preparing a masked frame, the client MUST pick a fresh masking key from the set of allowed 32-bit values. (§5.3)
- [ ] **MUST** The masking key needs to be unpredictable; thus, the masking key MUST be derived from a strong source of entropy, and the masking key for a given frame MUST NOT make it simple for a server/proxy to predict the masking key for a subsequent frame. (§5.3)
- [ ] **MUST NOT** The masking key needs to be unpredictable; thus, the masking key MUST be derived from a strong source of entropy, and the masking key for a given frame MUST NOT make it simple for a server/proxy to predict the masking key for a subsequent frame. (§5.3)
## Optional Requirements (MAY / OPTIONAL)
- [ ] **MAY** A client MUST close a connection if it detects a masked frame. In this case, it MAY use the status code 1002 (protocol error) as defined in Section 7.4.1. (§5.1)
- [ ] **MAY** A data frame MAY be transmitted by either the client or the server at any time after opening handshake completion and before that endpoint has sent a Close frame (Section 5.5.1). (§5.1)
- [ ] **MAY** The first fragment MAY also be the final fragment. (§5.2)
--- json ---
{
"rfc": 6455,
"role": "client",
"stats": {
"must": 13,
"should": 0,
"may": 3,
"total": 16
},
"_source": "text",
"_sourceNote": "Warning: Parsed from text format. Checklist accuracy may be limited."
}checklist-6455-server
Arguments: generate_checklist
json
{
"rfc": 6455,
"sections": [
"5.1",
"5.2",
"5.3"
],
"role": "server"
}Output (48 lines)
text
# checklist-6455-server
tool: generate_checklist
args: {"rfc":6455,"sections":["5.1","5.2","5.3"],"role":"server"}
--- markdown ---
# RFC 6455 Implementation Checklist
**The WebSocket Protocol**
Role: server
Generated: <generatedAt>
## Mandatory Requirements (MUST / REQUIRED / SHALL)
- [ ] **MUST** The server MUST close the connection upon receiving a frame that is not masked. (§5.1)
- [ ] **MUST NOT** A server MUST NOT mask any frames that it sends to the client. (§5.1)
- [ ] **MUST** RSV1, RSV2, RSV3: 1 bit each MUST be 0 unless an extension is negotiated that defines meanings for non-zero values. (§5.2)
- [ ] **MUST** If a nonzero value is received and none of the negotiated extensions defines the meaning of such a nonzero value, the receiving endpoint MUST _Fail the WebSocket Connection_. (§5.2)
- [ ] **MUST** If an unknown opcode is received, the receiving endpoint MUST _Fail the WebSocket Connection_. (§5.2)
- [ ] **MUST** If 127, the following 8 bytes interpreted as a 64-bit unsigned integer (the most significant bit MUST be 0) are the payload length. (§5.2)
- [ ] **MUST** Note that in all cases, the minimal number of bytes MUST be used to encode the length, for example, the length of a 124-byte-long string can't be encoded as the sequence 126, 0, 124. (§5.2)
- [ ] **MUST** Any extension MUST specify the length of the "Extension data", or how that length may be calculated, and how the extension use MUST be negotiated during the opening handshake. (§5.2)
- [ ] **MUST** 1 bit in length, MUST be 0 unless negotiated otherwise (§5.2)
- [ ] **MUST** A masked frame MUST have the field frame-masked set to 1, as defined in Section 5.2. (§5.3)
- [ ] **MUST** The masking key needs to be unpredictable; thus, the masking key MUST be derived from a strong source of entropy, and the masking key for a given frame MUST NOT make it simple for a server/proxy to predict the masking key for a subsequent frame. (§5.3)
- [ ] **MUST NOT** The masking key needs to be unpredictable; thus, the masking key MUST be derived from a strong source of entropy, and the masking key for a given frame MUST NOT make it simple for a server/proxy to predict the masking key for a subsequent frame. (§5.3)
## Optional Requirements (MAY / OPTIONAL)
- [ ] **MAY** (Note that masking is done whether or not the WebSocket Protocol is running over TLS.) The server MUST close the connection upon receiving a frame that is not masked. In this case, a server MAY send a Close frame with a status code of 1002 (protocol error) as defined in Section 7.4.1. (§5.1)
- [ ] **MAY** A data frame MAY be transmitted by either the client or the server at any time after opening handshake completion and before that endpoint has sent a Close frame (Section 5.5.1). (§5.1)
- [ ] **MAY** The first fragment MAY also be the final fragment. (§5.2)
--- json ---
{
"rfc": 6455,
"role": "server",
"stats": {
"must": 12,
"should": 0,
"may": 3,
"total": 15
},
"_source": "text",
"_sourceNote": "Warning: Parsed from text format. Checklist accuracy may be limited."
}checklist-2131-4.3.1
Arguments: generate_checklist
json
{
"rfc": 2131,
"sections": [
"4.3.1"
]
}Output (58 lines)
text
# checklist-2131-4.3.1
tool: generate_checklist
args: {"rfc":2131,"sections":["4.3.1"]}
--- markdown ---
# RFC 2131 Implementation Checklist
**Dynamic Host Configuration Protocol**
Generated: <generatedAt>
## Mandatory Requirements (MUST / REQUIRED / SHALL)
- [ ] **MUST NOT** Requested IP address MUST NOT MUST NOT MUST NOT (§4.3.1)
- [ ] **MUST** IP address lease time MUST MUST (DHCPREQUEST) MUST NOT (§4.3.1)
- [ ] **MUST NOT** IP address lease time MUST MUST (DHCPREQUEST) MUST NOT (§4.3.1)
- [ ] **MUST NOT** MUST NOT (DHCPINFORM) (§4.3.1)
- [ ] **MUST NOT** Use 'file'/'sname' fields MAY MAY MUST NOT (§4.3.1)
- [ ] **MUST NOT** Parameter request list MUST NOT MUST NOT MUST NOT (§4.3.1)
- [ ] **MUST NOT** Client identifier MUST NOT MUST NOT MAY (§4.3.1)
- [ ] **MUST** Server identifier MUST MUST MUST (§4.3.1)
- [ ] **MUST NOT** Maximum message size MUST NOT MUST NOT MUST NOT (§4.3.1)
- [ ] **MUST NOT** All others MAY MAY MUST NOT (§4.3.1)
- [ ] **MUST** The configuration parameters MUST be selected by applying the following rules in the order given below. (§4.3.1)
- [ ] **MUST** The server MUST return to the client: (§4.3.1)
- [ ] **MUST** -- IF the server has been explicitly configured with a default value for the parameter, the server MUST include that value in an appropriate option in the 'option' field, ELSE -- IF the server recognizes the parameter as a parameter defined in the Host Requirements Document, the server MUST include the default value for that parameter as given in the Host Requirements Document in an appropriate option in the 'option' field, ELSE -- The server MUST NOT return a value for that parameter, The server MUST supply as many of the requested parameters as possible and MUST omit any parameters it cannot provide. (§4.3.1)
- [ ] **MUST NOT** -- IF the server has been explicitly configured with a default value for the parameter, the server MUST include that value in an appropriate option in the 'option' field, ELSE -- IF the server recognizes the parameter as a parameter defined in the Host Requirements Document, the server MUST include the default value for that parameter as given in the Host Requirements Document in an appropriate option in the 'option' field, ELSE -- The server MUST NOT return a value for that parameter, The server MUST supply as many of the requested parameters as possible and MUST omit any parameters it cannot provide. (§4.3.1)
- [ ] **MUST** The server MUST include each requested parameter only once unless explicitly allowed in the DHCP Options and BOOTP Vendor Extensions document. (§4.3.1)
- [ ] **MUST** o Any parameters specific to this client (as identified by the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by the network administrator, o Any parameters specific to this client's class (as identified by the contents of the 'vendor class identifier' option in the DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by the network administrator; the parameters MUST be identified by an exact match between the client's vendor class identifiers and the client's classes identified in the server, o Parameters with non-default values on the client's subnet. (§4.3.1)
## Recommended Requirements (SHOULD / RECOMMENDED)
- [ ] **SHOULD** If an address is available, the new address SHOULD be chosen as follows: (§4.3.1)
- [ ] **SHOULD NOT** While not required for correct operation of DHCP, the server SHOULD NOT reuse the selected network address before the client responds to the server's DHCPOFFER message. (§4.3.1)
## Optional Requirements (MAY / OPTIONAL)
- [ ] **MAY** As described in section 4.2, a server MAY, for administrative reasons, assign an address other than the one requested, or may refuse to allocate an address to a particular client even though free addresses are available. (§4.3.1)
- [ ] **MAY** Use 'file'/'sname' fields MAY MAY MUST NOT (§4.3.1)
- [ ] **MAY** Client identifier MUST NOT MUST NOT MAY (§4.3.1)
- [ ] **MAY** Vendor class identifier MAY MAY MAY (§4.3.1)
- [ ] **MAY** All others MAY MAY MUST NOT (§4.3.1)
- [ ] **MAY** The server MAY choose to return the 'vendor class identifier' used to determine the parameters in the DHCPOFFER message to assist the client in selecting which DHCPOFFER to accept. (§4.3.1)
--- json ---
{
"rfc": 2131,
"role": "both",
"stats": {
"must": 16,
"should": 2,
"may": 6,
"total": 24
},
"_source": "text",
"_sourceNote": "Warning: Parsed from text format. Checklist accuracy may be limited."
}checklist-9113-8.3.1
Arguments: generate_checklist
json
{
"rfc": 9113,
"sections": [
"8.3.1"
]
}Output (48 lines)
text
# checklist-9113-8.3.1
tool: generate_checklist
args: {"rfc":9113,"sections":["8.3.1"]}
--- markdown ---
# RFC 9113 Implementation Checklist
**HTTP/2**
Generated: <generatedAt>
## Mandatory Requirements (MUST / REQUIRED / SHALL)
- [ ] **MUST NOT** The recipient of an HTTP/2 request MUST NOT use the Host header field to determine the target URI if ":authority" is present. (§8.3.1)
- [ ] **MUST** Clients that generate HTTP/2 requests directly MUST use the ":authority" pseudo-header field to convey authority information, unless there is no authority information to convey (in which case it MUST NOT generate ":authority"). (§8.3.1)
- [ ] **MUST NOT** Clients that generate HTTP/2 requests directly MUST use the ":authority" pseudo-header field to convey authority information, unless there is no authority information to convey (in which case it MUST NOT generate ":authority"). (§8.3.1)
- [ ] **MUST NOT** Clients MUST NOT generate a request with a Host header field that differs from the ":authority" pseudo-header field. (§8.3.1)
- [ ] **MUST** An origin server can apply any normalization method, whereas other servers MUST perform scheme-based normalization (see Section 6.2.3 of [RFC3986]) of the two fields. (§8.3.1)
- [ ] **MUST** An intermediary that forwards a request over HTTP/2 MUST construct an ":authority" pseudo-header field using the authority information from the control data of the original request, unless the original request's target URI does not contain authority information (in which case it MUST NOT generate ":authority"). (§8.3.1)
- [ ] **MUST NOT** An intermediary that forwards a request over HTTP/2 MUST construct an ":authority" pseudo-header field using the authority information from the control data of the original request, unless the original request's target URI does not contain authority information (in which case it MUST NOT generate ":authority"). (§8.3.1)
- [ ] **MUST** An intermediary that needs to generate a Host header field (which might be necessary to construct an HTTP/1.1 request) MUST use the value from the ":authority" pseudo-header field as the value of the Host field, unless the intermediary also changes the request target. (§8.3.1)
- [ ] **MUST NOT** ":authority" MUST NOT include the deprecated userinfo subcomponent for "http" or "https" schemed URIs. (§8.3.1)
- [ ] **MUST NOT** This pseudo-header field MUST NOT be empty for "http" or "https" URIs; "http" or "https" URIs that do not contain a path component MUST include a value of '/'. (§8.3.1)
- [ ] **MUST** This pseudo-header field MUST NOT be empty for "http" or "https" URIs; "http" or "https" URIs that do not contain a path component MUST include a value of '/'. (§8.3.1)
- [ ] **MUST** The exceptions to this rule are: an OPTIONS request for an "http" or "https" URI that does not include a path component; these MUST include a ":path" pseudo-header field with a value of '*' (see Section 7.1 of [HTTP]). (§8.3.1)
- [ ] **MUST** All HTTP/2 requests MUST include exactly one valid value for the ":method", ":scheme", and ":path" pseudo-header fields, unless they are CONNECT requests (Section 8.5). (§8.3.1)
## Recommended Requirements (SHOULD / RECOMMENDED)
- [ ] **SHOULD** A server SHOULD treat a request as malformed if it contains a Host header field that identifies an entity that differs from the entity in the ":authority" pseudo-header field. (§8.3.1)
## Optional Requirements (MAY / OPTIONAL)
- [ ] **MAY** An intermediary that forwards a request over HTTP/2 MAY retain any Host header field. (§8.3.1)
--- json ---
{
"rfc": 9113,
"role": "both",
"stats": {
"must": 13,
"should": 1,
"may": 1,
"total": 15
},
"_source": "xml"
}checklist-8259
Arguments: generate_checklist
json
{
"rfc": 8259
}Output (44 lines)
text
# checklist-8259
tool: generate_checklist
args: {"rfc":8259}
--- markdown ---
# RFC 8259 Implementation Checklist
**The JavaScript Object Notation (JSON) Data Interchange Format**
Generated: <generatedAt>
## Mandatory Requirements (MUST / REQUIRED / SHALL)
- [ ] **MUST** A JSON value MUST be an object, array, number, or string, or one of the following three literal names: (§3)
- [ ] **MUST** The literal names MUST be lowercase. (§3)
- [ ] **MUST** All Unicode characters may be placed within the quotation marks, except for the characters that MUST be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F). (§7)
- [ ] **MUST** JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [RFC3629]. (§8.1)
- [ ] **MUST NOT** Implementations MUST NOT add a byte order mark (U+FEFF) to the beginning of a networked-transmitted JSON text. (§8.1)
- [ ] **MUST** A JSON parser MUST accept all texts that conform to the JSON grammar. (§9)
- [ ] **MUST** The resulting text MUST strictly conform to the JSON grammar. (§10)
## Recommended Requirements (SHOULD / RECOMMENDED)
- [ ] **SHOULD** The names within an object SHOULD be unique. (§4)
## Optional Requirements (MAY / OPTIONAL)
- [ ] **MAY** In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error. (§8.1)
- [ ] **MAY** A JSON parser MAY accept non-JSON forms or extensions. (§9)
--- json ---
{
"rfc": 8259,
"role": "both",
"stats": {
"must": 7,
"should": 1,
"may": 2,
"total": 10
},
"_source": "text",
"_sourceNote": "Warning: Parsed from text format. Checklist accuracy may be limited."
}checklist-5652-5.3
Arguments: generate_checklist
json
{
"rfc": 5652,
"sections": [
"5.3"
]
}Output (45 lines)
text
# checklist-5652-5.3
tool: generate_checklist
args: {"rfc":5652,"sections":["5.3"]}
--- markdown ---
# RFC 5652 Implementation Checklist
**Cryptographic Message Syntax (CMS)**
Generated: <generatedAt>
## Mandatory Requirements (MUST / REQUIRED / SHALL)
- [ ] **MUST** If the SignerIdentifier is the CHOICE issuerAndSerialNumber, then the version MUST be 1. (§5.3)
- [ ] **MUST** If the SignerIdentifier is subjectKeyIdentifier, then the version MUST be 3. (§5.3)
- [ ] **MUST** Implementations MUST support the reception of the issuerAndSerialNumber and subjectKeyIdentifier forms of SignerIdentifier. (§5.3)
- [ ] **MUST** However, subjectKeyIdentifier MUST be used to refer to a public key contained in a non-X.509 certificate. (§5.3)
- [ ] **MUST** The field is optional, but it MUST be present if the content type of the EncapsulatedContentInfo value being signed is not id-data. (§5.3)
- [ ] **MUST** SignedAttributes MUST be DER encoded, even if the rest of the structure is BER encoded. (§5.3)
- [ ] **MUST** If the field is present, it MUST contain, at a minimum, the following two attributes: (§5.3)
- [ ] **MUST NOT** However, the content-type attribute MUST NOT be used as part of a countersignature unsigned attribute as defined in Section 11.4. (§5.3)
## Recommended Requirements (SHOULD / RECOMMENDED)
- [ ] **SHOULD** The message digest algorithm SHOULD be among those listed in the digestAlgorithms field of the associated SignerData. (§5.3)
## Optional Requirements (MAY / OPTIONAL)
- [ ] **MAY** When generating a SignerIdentifier, implementations MAY support one of the forms (either issuerAndSerialNumber or subjectKeyIdentifier) and always use it, or implementations MAY arbitrarily mix the two forms. (§5.3)
- [ ] **MAY** Implementations MAY fail to validate signatures that use a digest algorithm that is not included in the SignedData digestAlgorithms set. (§5.3)
--- json ---
{
"rfc": 5652,
"role": "both",
"stats": {
"must": 8,
"should": 1,
"may": 2,
"total": 11
},
"_source": "text",
"_sourceNote": "Warning: Parsed from text format. Checklist accuracy may be limited."
}validate_statement
validate-6455-compliant
Arguments: validate_statement
json
{
"rfc": 6455,
"statement": "The client MUST mask all frames sent to the server."
}Output (219 lines)
text
# validate-6455-compliant
tool: validate_statement
args: {"rfc":6455,"statement":"The client MUST mask all frames sent to the server."}
--- json ---
{
"rfc": 6455,
"statement": "The client MUST mask all frames sent to the server.",
"analysis": {
"detectedLevel": "MUST",
"detectedSubject": "client"
},
"isValid": true,
"matchingRequirements": [
{
"id": "R-5.3-2",
"level": "MUST",
"text": "When preparing a masked frame, the client MUST pick a fresh masking key from the set of allowed 32-bit values.",
"section": "5.3",
"sectionTitle": "Client-to-Server Masking",
"fullContext": "The masking key is a 32-bit value chosen at random by the client. When preparing a masked frame, the client MUST pick a fresh masking key from the set of allowed 32-bit values. The masking key needs to be unpredictable; thus, the masking key MUST be derived from a strong source of entropy, and the masking key for a given frame MUST NOT make it simple for a server/proxy to predict the masking key for a subsequent frame. The unpredictability of the masking key is essential to prevent authors of malicious applications from selecting the bytes that appear on the wire. RFC 4086 [RFC4086] discusses what entails a suitable source of entropy for security-sensitive applications.",
"subject": "client",
"condition": "preparing a masked frame",
"action": "pick a fresh masking key from the set of allowed 32-bit values",
"_matchScore": 17,
"_matchedKeywords": [
"client",
"mask",
"frames"
],
"_contextKeywords": [
"sent",
"server"
],
"_subjectMatch": true,
"_levelMatch": true
},
{
"id": "R-5.1-1",
"level": "MUST",
"text": "To avoid confusing network intermediaries (such as intercepting proxies) and for security reasons that are further discussed in Section 10.3, a client MUST mask all frames that it sends to the server (see Section 5.3 for further details).",
"section": "5.1",
"sectionTitle": "Overview",
"fullContext": "In the WebSocket Protocol, data is transmitted using a sequence of frames. To avoid confusing network intermediaries (such as intercepting proxies) and for security reasons that are further discussed in Section 10.3, a client MUST mask all frames that it sends to the server (see Section 5.3 for further details). (Note that masking is done whether or not the WebSocket Protocol is running over TLS.) The server MUST close the connection upon receiving a frame that is not masked. In this case, a server MAY send a Close frame with a status code of 1002 (protocol error) as defined in Section 7.4.1. A server MUST NOT mask any frames that it sends to the client. A client MUST close a connection if it detects a masked frame. In this case, it MAY use the status code 1002 (protocol error) as defined in Section 7.4.1. (These rules might be relaxed in a future specification.) The base framing protocol defines a frame type with an opcode, a payload length, and designated locations for \"Extension data\" and \"Application data\", which together define the \"Payload data\". Certain bits and opcodes are reserved for future expansion of the protocol.",
"subject": "client",
"action": "mask all frames that it sends to the server (see Section 5.3 for further details)",
"_matchScore": 16,
"_matchedKeywords": [
"client",
"mask",
"frames",
"server"
],
"_subjectMatch": true,
"_levelMatch": true
},
{
"id": "R-5.1-5",
"level": "MUST",
… (219 lines)validate-6455-violation
Arguments: validate_statement
json
{
"rfc": 6455,
"statement": "The client sends unmasked frames to the server."
}Output (235 lines)
text
# validate-6455-violation
tool: validate_statement
args: {"rfc":6455,"statement":"The client sends unmasked frames to the server."}
--- json ---
{
"rfc": 6455,
"statement": "The client sends unmasked frames to the server.",
"analysis": {
"detectedLevel": null,
"detectedSubject": "client"
},
"isValid": false,
"matchingRequirements": [
{
"id": "R-5.1-1",
"level": "MUST",
"text": "To avoid confusing network intermediaries (such as intercepting proxies) and for security reasons that are further discussed in Section 10.3, a client MUST mask all frames that it sends to the server (see Section 5.3 for further details).",
"section": "5.1",
"sectionTitle": "Overview",
"fullContext": "In the WebSocket Protocol, data is transmitted using a sequence of frames. To avoid confusing network intermediaries (such as intercepting proxies) and for security reasons that are further discussed in Section 10.3, a client MUST mask all frames that it sends to the server (see Section 5.3 for further details). (Note that masking is done whether or not the WebSocket Protocol is running over TLS.) The server MUST close the connection upon receiving a frame that is not masked. In this case, a server MAY send a Close frame with a status code of 1002 (protocol error) as defined in Section 7.4.1. A server MUST NOT mask any frames that it sends to the client. A client MUST close a connection if it detects a masked frame. In this case, it MAY use the status code 1002 (protocol error) as defined in Section 7.4.1. (These rules might be relaxed in a future specification.) The base framing protocol defines a frame type with an opcode, a payload length, and designated locations for \"Extension data\" and \"Application data\", which together define the \"Payload data\". Certain bits and opcodes are reserved for future expansion of the protocol.",
"subject": "client",
"action": "mask all frames that it sends to the server (see Section 5.3 for further details)",
"_matchScore": 13,
"_matchedKeywords": [
"client",
"sends",
"frames",
"server"
],
"_subjectMatch": true,
"_levelMatch": false
},
{
"id": "R-5.1-5",
"level": "MUST",
"text": "A client MUST close a connection if it detects a masked frame.",
"section": "5.1",
"sectionTitle": "Overview",
"fullContext": "In the WebSocket Protocol, data is transmitted using a sequence of frames. To avoid confusing network intermediaries (such as intercepting proxies) and for security reasons that are further discussed in Section 10.3, a client MUST mask all frames that it sends to the server (see Section 5.3 for further details). (Note that masking is done whether or not the WebSocket Protocol is running over TLS.) The server MUST close the connection upon receiving a frame that is not masked. In this case, a server MAY send a Close frame with a status code of 1002 (protocol error) as defined in Section 7.4.1. A server MUST NOT mask any frames that it sends to the client. A client MUST close a connection if it detects a masked frame. In this case, it MAY use the status code 1002 (protocol error) as defined in Section 7.4.1. (These rules might be relaxed in a future specification.) The base framing protocol defines a frame type with an opcode, a payload length, and designated locations for \"Extension data\" and \"Application data\", which together define the \"Payload data\". Certain bits and opcodes are reserved for future expansion of the protocol.",
"subject": "client",
"condition": "it detects a masked frame",
"action": "close a connection if it detects a masked frame",
"_matchScore": 13,
"_matchedKeywords": [
"client",
"frames"
],
"_contextKeywords": [
"sends",
"server"
],
"_subjectMatch": true,
"_levelMatch": false
},
{
"id": "R-5.1-6",
"level": "MAY",
"text": "In this case, it MAY use the status code 1002 (protocol error) as defined in Section 7.4.1.",
… (235 lines)validate-6455-passive
Arguments: validate_statement
json
{
"rfc": 6455,
"statement": "The fragments of one message are interleaved between the fragments of another message."
}Output (202 lines)
text
# validate-6455-passive
tool: validate_statement
args: {"rfc":6455,"statement":"The fragments of one message are interleaved between the fragments of another message."}
--- json ---
{
"rfc": 6455,
"statement": "The fragments of one message are interleaved between the fragments of another message.",
"analysis": {
"detectedLevel": null,
"detectedSubject": null
},
"isValid": null,
"_verdictNote": "isValid is null: requirement R-5.4-4 forbids this in the passive voice, so who performs the act cannot be matched. Read that requirement and decide. This is not a statement of compliance.",
"matchingRequirements": [
{
"id": "R-5.4-4",
"level": "MUST NOT",
"text": "The fragments of one message MUST NOT be interleaved between the fragments of another message unless an extension has been negotiated that can interpret the interleaving.",
"section": "5.4",
"sectionTitle": "Fragmentation",
"fullContext": "The fragments of one message MUST NOT be interleaved between the fragments of another message unless an extension has been negotiated that can interpret the interleaving.",
"subject": "one message",
"exception": "an extension has been negotiated that can interpret the interleaving",
"action": "be interleaved between the fragments of another message unless an extension has been negotiated that can interpret the interleaving",
"_matchScore": 8,
"_matchedKeywords": [
"fragments",
"message",
"interleaved",
"another"
],
"_subjectMatch": false,
"_levelMatch": false
},
{
"id": "R-5.2-1",
"level": "MAY",
"text": "The first fragment MAY also be the final fragment.",
"section": "5.2",
"sectionTitle": "Base Framing Protocol",
"fullContext": "FIN: 1 bit Indicates that this is the final fragment in a message. The first fragment MAY also be the final fragment.",
"subject": "first fragment",
"action": "also be the final fragment",
"_matchScore": 6,
"_matchedKeywords": [
"fragments"
],
"_contextKeywords": [
"message"
],
"_subjectMatch": false,
"_levelMatch": false
},
{
"id": "R-5.4-1",
"level": "MAY",
"text": "Control frames (see Section 5.5) MAY be injected in the middle of a fragmented message.",
"section": "5.4",
… (202 lines)validate-7159-own-sentence
Arguments: validate_statement
json
{
"rfc": 7159,
"statement": "In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error."
}Output (171 lines)
text
# validate-7159-own-sentence
tool: validate_statement
args: {"rfc":7159,"statement":"In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error."}
--- json ---
{
"rfc": 7159,
"statement": "In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.",
"analysis": {
"detectedLevel": "MAY",
"detectedSubject": "implementation"
},
"isValid": true,
"matchingRequirements": [
{
"id": "R-8.1-3",
"level": "MAY",
"text": "In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.",
"section": "8.1",
"sectionTitle": "Character Encoding",
"fullContext": "Implementations MUST NOT add a byte order mark to the beginning of a JSON text. In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.",
"subject": "json texts",
"action": "ignore the presence of a byte order mark rather than treating it as an error",
"_matchScore": 23,
"_matchedKeywords": [
"interests",
"interoperability",
"implementations",
"parse",
"json",
"texts",
"ignore",
"presence",
"byte",
"order",
"mark",
"rather",
"treating",
"error"
],
"_subjectMatch": true,
"_levelMatch": true
},
{
"id": "R-8.1-2",
"level": "MUST NOT",
"text": "Implementations MUST NOT add a byte order mark to the beginning of a JSON text.",
"section": "8.1",
"sectionTitle": "Character Encoding",
"fullContext": "Implementations MUST NOT add a byte order mark to the beginning of a JSON text. In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.",
"subject": "implementations",
"action": "add a byte order mark to the beginning of a JSON text",
"_matchScore": 20,
"_matchedKeywords": [
"implementations",
"json",
"texts",
"byte",
"order",
… (171 lines)validate-9110-qualifier
Arguments: validate_statement
json
{
"rfc": 9110,
"statement": "The origin server generates a Date header field even though it has no clock."
}Output (228 lines)
text
# validate-9110-qualifier
tool: validate_statement
args: {"rfc":9110,"statement":"The origin server generates a Date header field even though it has no clock."}
--- json ---
{
"rfc": 9110,
"statement": "The origin server generates a Date header field even though it has no clock.",
"analysis": {
"detectedLevel": null,
"detectedSubject": "server"
},
"isValid": null,
"_verdictNote": "isValid is null: requirement R-6.6.1-4 turns on \"without\", a word the statement does not use, so whether they describe the same case cannot be decided. This is not a statement of compliance.",
"matchingRequirements": [
{
"id": "R-6.6.1-2",
"level": "MUST",
"text": "An origin server with a clock (as defined in Section 5.6.7) MUST generate a Date header field in all 2xx (Successful), 3xx (Redirection), and 4xx (Client Error) responses, and MAY generate a Date header field in 1xx (Informational) and 5xx (Server Error) responses.",
"section": "6.6.1",
"sectionTitle": "Date",
"fullContext": "An origin server with a clock (as defined in Section 5.6.7) MUST generate a Date header field in all 2xx (Successful), 3xx (Redirection), and 4xx (Client Error) responses, and MAY generate a Date header field in 1xx (Informational) and 5xx (Server Error) responses.",
"action": "generate a Date header field in all 2xx (Successful), 3xx (Redirection), and 4xx (Client Error) responses, and MAY generate a Date header field in 1xx (Informational) and 5xx (Server Error) responses",
"_matchScore": 17,
"_matchedKeywords": [
"origin",
"server",
"generates",
"date",
"header",
"field",
"clock"
],
"_subjectMatch": true,
"_levelMatch": false
},
{
"id": "R-6.6.1-3",
"level": "MAY",
"text": "An origin server with a clock (as defined in Section 5.6.7) MUST generate a Date header field in all 2xx (Successful), 3xx (Redirection), and 4xx (Client Error) responses, and MAY generate a Date header field in 1xx (Informational) and 5xx (Server Error) responses.",
"section": "6.6.1",
"sectionTitle": "Date",
"fullContext": "An origin server with a clock (as defined in Section 5.6.7) MUST generate a Date header field in all 2xx (Successful), 3xx (Redirection), and 4xx (Client Error) responses, and MAY generate a Date header field in 1xx (Informational) and 5xx (Server Error) responses.",
"action": "generate a Date header field in 1xx (Informational) and 5xx (Server Error) responses",
"_matchScore": 17,
"_matchedKeywords": [
"origin",
"server",
"generates",
"date",
"header",
"field",
"clock"
],
"_subjectMatch": true,
"_levelMatch": false
},
{
"id": "R-6.6.1-4",
… (228 lines)