diff --git a/erts/doc/guides/tty.md b/erts/doc/guides/tty.md index d3094f313a03..3d9afb336a04 100644 --- a/erts/doc/guides/tty.md +++ b/erts/doc/guides/tty.md @@ -55,46 +55,46 @@ Typographic conventions: - When a function has multiple possible key sequences they are listed on individual lines in the `Key Sequence` column. -| _Key Sequence_ | _Function_ | -| -------------------- | ----------------------------------------------------------------| -| `Home` | Beginning of line | -| `C-a` | Beginning of line | -| `C-b` | Backward character | -| `C-Left` or `M-Left` | Backward word | -| `M-b` | Backward word | -| `C-d` | Delete character | -| `M-d` | Delete word | -| `End` | End of line | -| `C-e` | End of line | -| `C-f` | Forward character | -| `C-Right` or `M-Right` | Forward word | -| `M-f` | Forward word | -| `C-g` | Enter shell break mode | -| `C-k` | Kill line | -| `C-u` | Backward kill line | -| `C-l` | Clears the screen | -| `M-c` | Clears the current expression | -| `M-l` | Redraw line | -| `C-n` | Fetch next line from the history buffer | -| `C-o` or `M-o` | Edit the current line using the editor specified in the environment variable `VISUAL` or `EDITOR`. The environment variables can contain arguments to the editor if needed, for example `VISUAL="emacs -nw"`. On Windows the editor cannot be a console based editor. | -| `C-p` | Fetch previous line from the history buffer | -| `M-r` | Format current expression using `shell:format_shell_func/1` | -| `C-r` | Enter search mode and then search backward in the shell history | -| `C-s` | In search mode, search forward in the shell history | -| `C-t` | Transpose characters | -| `C-w` | Backward kill word | -| `C-y` | Insert previously killed text | -| `C-]` | Insert matching closing bracket | -| `C-Up` or `M-Up` | Navigate one row up when editing multiple lines | -| `C-Down` or `M-Down` | Navigate one row down when editing multiple lines | -| `M-Enter` | Insert a new line at cursor | -| `M-<` or `M-S-Up` | Navigate to the start of the current expression | -| `M->` or `M-S-Down` | Navigate to the end of the current expression | -| `Tab` or `C-i` | Autocomplete current expression, or show completion suggestions | -| `M-c` | Clear current expression | -| `M-h` | Display help for the module or function closest on the left of the cursor.| -| `PageUp` | Scroll the expand, search or help buffer 5 lines upwards. | -| `PageDown` | Scroll the expand, search or help buffer 5 lines downwards. | +| Key Sequence | Function | +| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Home` | Beginning of line | +| `C-a` | Beginning of line | +| `C-b` | Backward character | +| `C-Left` or `M-Left` | Backward word | +| `M-b` | Backward word | +| `C-d` | Delete character | +| `M-d` | Delete word | +| `End` | End of line | +| `C-e` | End of line | +| `C-f` | Forward character | +| `C-Right` or `M-Right` | Forward word | +| `M-f` | Forward word | +| `C-g` | Enter shell break mode | +| `C-k` | Kill line | +| `C-u` | Backward kill line | +| `C-l` | Clears the screen | +| `M-c` | Clears the current expression | +| `M-l` | Redraw line | +| `C-n` | Fetch next line from the history buffer | +| `C-o` or `M-o` | Edit the current line using the editor specified in the environment variable `VISUAL` or `EDITOR`. The environment variables can contain arguments to the editor if needed, for example `VISUAL="emacs -nw"`. On Windows the editor cannot be a console based editor. | +| `C-p` | Fetch previous line from the history buffer | +| `M-r` | Format current expression using `shell:format_shell_func/1` | +| `C-r` | Enter search mode and then search backward in the shell history | +| `C-s` | In search mode, search forward in the shell history | +| `C-t` | Transpose characters | +| `C-w` | Backward kill word | +| `C-y` | Insert previously killed text | +| `C-]` | Insert matching closing bracket | +| `C-Up` or `M-Up` | Navigate one row up when editing multiple lines | +| `C-Down` or `M-Down` | Navigate one row down when editing multiple lines | +| `M-Enter` | Insert a new line at cursor | +| `M-<` or `M-S-Up` | Navigate to the start of the current expression | +| `M->` or `M-S-Down` | Navigate to the end of the current expression | +| `Tab` or `C-i` | Autocomplete current expression, or show completion suggestions | +| `M-c` | Clear current expression | +| `M-h` | Display help for the module or function closest on the left of the cursor. | +| `PageUp` | Scroll the expand, search or help buffer 5 lines upwards. | +| `PageDown` | Scroll the expand, search or help buffer 5 lines downwards. | _Table: tty Text Editing_ diff --git a/lib/asn1/doc/guides/asn1_getting_started.md b/lib/asn1/doc/guides/asn1_getting_started.md index e9a0d9319401..e0768a176020 100644 --- a/lib/asn1/doc/guides/asn1_getting_started.md +++ b/lib/asn1/doc/guides/asn1_getting_started.md @@ -312,7 +312,7 @@ and how values are assigned in Erlang. ASN.1 has both primitive and constructed types: -| _Primitive Types_ | _Constructed Types_ | +| Primitive Types | Constructed Types | | -------------------------------------------------------------- | ------------------------------------------------------------ | | [BOOLEAN](asn1_getting_started.md#boolean) | [SEQUENCE](asn1_getting_started.md#sequence) | | [INTEGER](asn1_getting_started.md#integer) | [SET](asn1_getting_started.md#set) | diff --git a/lib/common_test/doc/guides/ct_hooks_chapter.md b/lib/common_test/doc/guides/ct_hooks_chapter.md index 7f4e907e631c..b8e503467219 100644 --- a/lib/common_test/doc/guides/ct_hooks_chapter.md +++ b/lib/common_test/doc/guides/ct_hooks_chapter.md @@ -123,7 +123,7 @@ following table. Function [init/2](`c:ct_hooks:init/2`) is called at the beginning of the scope and function [terminate/1](`c:ct_hooks:terminate/1`) is called when the scope ends. -| _CTH installed in_ | _CTH scope begins before_ | _CTH scope ends after_ | +| CTH installed in | CTH scope begins before | CTH scope ends after | | ------------------------------------------------------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | [ct_run](run_test_chapter.md#ct_run) | the first test suite is to be run | the last test suite has been run | | [ct:run_test](`ct:run_test/1`) | the first test suite is run | the last test suite has been run | diff --git a/lib/diameter/doc/guides/diameter_soc.md b/lib/diameter/doc/guides/diameter_soc.md index 4742197bf9c0..d9c2deb4e5c7 100644 --- a/lib/diameter/doc/guides/diameter_soc.md +++ b/lib/diameter/doc/guides/diameter_soc.md @@ -35,195 +35,195 @@ Erlang application. ## RFC 6733 - Diameter Base Protocol -| _Section_ | _Title_ | _Compliance_ | _Notes_ | -| --------- | ----------------------------------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1 | Introduction | — | | -| 1\.1 | Diameter Protocol | — | | -| 1\.1.1 | Description of the Document Set | — | | -| 1\.1.2 | Conventions Used in This Document | — | | -| 1\.1.3 | Changes from RFC 3588 | — | It is possible to configure a 3588 dictionary in order to get 3588 semantics, where the differ from 6733. | -| 1\.2 | Terminology | — | | -| 1\.3 | Approach to Extensibility | — | The dictionary interface documented in [diameter_dict(4)](diameter_dict.md) provides extensibility, allowing the user to defined new AVPs, commands, and applications. Ready dictionaries are provided for the RFC 6733 common message, base accounting, and relay applications, as well as for RFC 7683, Diameter Overload Indicator Conveyance. | -| 1\.3.1 | Defining New AVP Values | — | | -| 1\.3.2 | Creating New AVPs | — | New AVPs can be defined using the dictionary interface. Both RFC data formats and extensions are supported. | -| 1\.3.3 | Creating New Commands | — | New commands can be defined using the dictionary interface. | -| 1\.3.4 | Creating New Diameter Applications | — | New applications can be defined using the dictionary interface. | -| 2 | Protocol Overview | — | Session state is the responsibility of the user.   The role of a Diameter node is determined by the user's implementation. | -| 2\.1 | Transport | PC | Ports are configured by the user: diameter places no restrictions.   The transport interface documented in `m:diameter_transport` allows the user to implement their own methods. Ready support is provided for TCP, TCP/TLS, and SCTP, but not DTLS/SCTP.   Multiple connections to the same peer is possible. ICMP messages are not interpreted. | -| 2\.1.1 | SCTP Guidelines | C | Unordered sending is configurable in `m:diameter_sctp`. There is no special handling of DPR/DPA: since a user that cares about pending answers should wait for them before initiating DPR.   A PPID can be configured with a a gen_sctp sctp_default_send_param option. | -| 2\.2 | Securing Diameter Messages | PC | DTLS is not supported by `m:diameter_sctp`. See also 2.1. | -| 2\.3 | Diameter Application Compliance | — | | -| 2\.4 | Application Identifiers | C | The user configures diameter with the identifiers to send at capabilities exchange, along with corresponding dictionaries defining the messages of the applications. | -| 2\.5 | Connections vs. Sessions | C | Connections are realized by configuring transport. Sessions are the responsibility of the user. | -| 2\.6 | Peer Table | PC | Routing is implemented by the user in callbacks documented in `m:diameter_app`. A peer table of the documented form is not exposed to the user. | -| 2\.7 | Routing Table | PC | See 2.6. A routing table of the documented form is not exposed to the user. | -| 2\.8 | Role of Diameter Agents | C | Most role-specific behaviour is implemented by the user. How a node advertises itself at capabilities exchange is determined by user configuration. | -| 2\.8.1 | Relay Agents | C | | -| 2\.8.2 | Proxy Agents | C | | -| 2\.8.3 | Redirect Agents | C | | -| 2\.8.4 | Translation Agents | C | | -| 2\.9 | Diameter Path Authorization | — | Authorization is the responsibility of the user. | -| 3 | Diameter Header | C | Hop-by-Hop and End-to-End Identifiers are set by diameter when sending outgoing requests. | -| 3\.1 | Command Codes | C | | -| 3\.2 | Command Code Format Specification | C | Commands are defined as CCF specifications in dictionary files. | -| 3\.3 | Diameter Command Naming Conventions | — | | -| 4 | Diameter AVPs | C | Any required padding is added by diameter when encoding outgoing messages. | -| 4\.1 | AVP Header | C | | -| 4\.1.1 | Optional Header Elements | C | | -| 4\.2 | Basic AVP Data Formats | C | | -| 4\.3 | Derived AVP Data Formats | C | Arbitrary derived data formats are supported by the dictionary interface. | -| 4\.3.1 | Common Derived AVP Data Formats | C | Beware that RFC 6733 changed the DiameterURI transport/port defaults specified in RFC3588. Relying on the defaults can result in interoperability problems. | -| 4\.4 | Grouped AVP Values | C | The M-bit on a component AVP of a Grouped AVP that does not set M is ignored: such AVPs are not regarded as erroneous at decode.   Grouped AVPs are defined as CCF specifications in dictionary files. | -| 4\.4.1 | Example AVP with a Grouped Data Type | — | | -| 4\.5 | Diameter Base Protocol AVPs | C | The base AVPs are defined in the common dictionary provided by diameter. There are common dictionaries for both RFC 3588 and RFC 6733 since the latter made changes to both syntax and semantics. | -| 5 | Diameter Peers | — | | -| 5\.1 | Peer Connections | PC | A peer's DiameterIdentity is not required when initiating a connection: the identify is received at capabilities exchange, at which time the connection can be rejected if the identity is objectionable.   The number of connections established depends on the user's configuration. Multiple connections per peer is possible. | -| 5\.2 | Diameter Peer Discovery | NC | No form of peer discovery is implemented. The user can implement this independently of diameter if required. | -| 5\.3 | Capabilities Exchange | C | All supported applications are sent in CEA. The user can reject an incoming CER or CEA in a configured callback.   Both transport security at connection establishment and negotiated via an Inband-Security AVP are supported. | -| 5\.3.1 | Capabilities-Exchange-Request | C | CER is sent and received by diameter. | -| 5\.3.2 | Capabilities-Exchange-Answer | C | CEA is sent and received by diameter. | -| 5\.3.3 | Vendor-Id AVP | C | | -| 5\.3.4 | Firmware-Revision AVP | C | | -| 5\.3.5 | Host-IP-Address AVP | C | | -| 5\.3.6 | Supported-Vendor-Id AVP | C | | -| 5\.3.7 | Product-Name AVP | C | | -| 5\.4 | Disconnecting Peer Connections | C | DPA will not be answered with error: a peer that wants to a avoid a race can wait for pending answers before sending DPR. | -| 5\.4.1 | Disconnect-Peer-Request | C | DPR is sent by diameter in response to configuration changes requiring a connection to be broken. The user can also send DPR. | -| 5\.4.2 | Disconnect-Peer-Answer | C | DPR is answered by diameter. | -| 5\.4.3 | Disconnect-Cause AVP | C | | -| 5\.5 | Transport Failure Detection | — | | -| 5\.5.1 | Device-Watchdog-Request | C | DWR is sent and received by diameter. Callbacks notify the user of transitions into and out of the OKAY state. | -| 5\.5.2 | Device-Watchdog-Answer | C | DWA is sent and received by diameter. | -| 5\.5.3 | Transport Failure Algorithm | C | | -| 5\.5.4 | Failover and Failback Procedures | C | | -| 5\.6 | Peer State Machine | PC | The election process is modified as described in 5.6.4. | -| 5\.6.1 | Incoming Connections | C | | -| 5\.6.2 | Events | — | | -| 5\.6.3 | Actions | — | | -| 5\.6.4 | The Election Process | PC | As documented, the election assumes knowledge of a peer's DiameterIdentity when initiating a connection, which diameter doesn't require. Connections will be accepted if configuration allows multiple connections per peer to be established or there is no existing connection. Note that the election process is only applicable when multiple connections per peer is disallowed. | -| 6 | Diameter Message Processing | — | | -| 6\.1 | Diameter Request Routing Overview | — | Routing is performed by the user. A callback from diameter provides a list of available suitable peer connections. | -| 6\.1.1 | Originating a Request | C | Requests are constructed by the user; diameter sets header fields as defined in the relevant dictionary. | -| 6\.1.2 | Sending a Request | C | | -| 6\.1.3 | Receiving Requests | C | Loops are detected by diameter when the return value of a request callback asks that a request be forwarded. Loop detection in other cases is the responsibility of the user. | -| 6\.1.4 | Processing Local Requests | C | The user decides whether or not to process a request locally in the request callback from diameter. | -| 6\.1.5 | Request Forwarding | PC | See 2.6. | -| 6\.1.6 | Request Routing | PC | See 2.7. | -| 6\.1.7 | Predictive Loop Avoidance | C | See 6.1.3. | -| 6\.1.8 | Redirecting Requests | PC | See 2.6. | -| 6\.1.9 | Relaying and Proxying Requests | C | A Route-Record AVP is appended by diameter when the return value of a request callback asks that a request be forwarded. Appending the AVP in other cases is the responsibility of the user. | -| 6\.2 | Diameter Answer Processing | C | Answer message are constructed by the user, except in the case of some protocol errors, in which case the procedures are followed. | -| 6\.2.1 | Processing Received Answers | C | Answers with an unknown Hop-by-Hop Identifier are discarded. | -| 6\.2.2 | Relaying and Proxying Answers | — | Modifying answers is the responsibility of the user in callbacks from diameter. | -| 6\.3 | Origin-Host AVP | C | The order of AVPs in an encoded message is determined by the CCF of the message in question.   AVPs defined in the RFC are defined in dictionaries provided by diameter. Their proper use in application messages is the responsibility of the user. | -| 6\.4 | Origin-Realm AVP | C | | -| 6\.5 | Destination-Host AVP | C | | -| 6\.6 | Destination-Realm AVP | C | | -| 6\.7 | Routing AVPs | — | | -| 6\.7.1 | Route-Record AVP | C | | -| 6\.7.2 | Proxy-Info AVP | C | | -| 6\.7.3 | Proxy-Host AVP | C | | -| 6\.7.4 | Proxy-State AVP | C | | -| 6\.8 | Auth-Application-Id AVP | C | | -| 6\.9 | Acct-Application-Id AVP | C | | -| 6\.10 | Inband-Security-Id AVP | C | See 2.1. | -| 6\.11 | Vendor-Specific-Application-Id AVP | C | Note that the CCF of this AVP is not the same as in RFC 3588. | -| 6\.12 | Redirect-Host AVP | C | | -| 6\.13 | Redirect-Host-Usage AVP | C | | -| 6\.14 | Redirect-Max-Cache-Time AVP | C | | -| 7 | Error Handling | C | Answers are formulated by the user in most cases. Answers setting the E-bit can be sent by diameter itself in response to a request that cannot be handled by the user. | -| 7\.1 | Result-Code AVP | C | | -| 7\.1.1 | Informational | C | | -| 7\.1.2 | Success | C | | -| 7\.1.3 | Protocol Errors | C | Result codes 3001, 3002, 3005, and 3007 can be sent in answers formulated by diameter, if configured to do so. | -| 7\.1.4 | Transient Failures | C | Result code 4003 is sent in CEA if there is an existing connection to the peer in question and configuration does not allow more than one. | -| 7\.1.5 | Permanent Failures | C | Message reception detects 5001, 5004, 5005, 5008, 5009, 5010, 5011, 5014, 5015, and 5017 errors. It ignores 5013 errors at the admonition of sections 3 and 4.1.   Note that RFC 3588 did not allow 5xxx result codes in answers setting the E-bit, while RFC 6733 does. This is a potential interoperability problem since the Diameter protocol version has not changed. | -| 7\.2 | Error Bit | C | | -| 7\.3 | Error-Message AVP | C | The user can include this AVP as required. | -| 7\.4 | Error-Reporting-Host AVP | C | The user can include this AVP as required. | -| 7\.5 | Failed-AVP AVP | C | The user constructs application-specific messages, but diameter provides failed AVPs in message callbacks. Failed component AVPs are grouped within the relevant Grouped AVPs. | -| 7\.6 | Experimental-Result AVP | C | | -| 7\.7 | Experimental-Result-Code AVP | C | | -| 8 | Diameter User Sessions | — | Authorization and accounting AVPs are defined in provided dictionaries. Their proper use is the responsibility of the user. | -| 8\.1 | Authorization Session State Machine | — | Authorization is the responsibility of the user: diameter does not implement this state machine. | -| 8\.2 | Accounting Session State Machine | — | Accounting is the responsibility of the user: diameter does not implement this state machine. | -| 8\.3 | Server-Initiated Re-Auth | — | | -| 8\.3.1 | Re-Auth-Request | C | | -| 8\.3.2 | Re-Auth-Answer | C | | -| 8\.4 | Session Termination | — | Session-related messages and AVPs are defined in provided dictionaries. Their proper use is the user's responsibility. | -| 8\.4.1 | Session-Termination-Request | C | | -| 8\.4.2 | Session-Termination-Answer | C | | -| 8\.5 | Aborting a Session | — | Session-related messages and AVPs are defined in provided dictionaries. Their proper use is the user's responsibility. | -| 8\.5.1 | Abort-Session-Request | C | | -| 8\.5.2 | Abort-Session-Answer | C | | -| 8\.6 | Inferring Session Termination from Origin-State-Id | — | Session-related messages and AVPs are defined in provided dictionaries. Their proper use is the user's responsibility. | -| 8\.7 | Auth-Request-Type AVP | C | | -| 8\.8 | Session-Id AVP | C | | -| 8\.9 | Authorization-Lifetime AVP | C | | -| 8\.10 | Auth-Grace-Period AVP | C | | -| 8\.11 | Auth-Session-State AVP | C | | -| 8\.12 | Re-Auth-Request-Type AVP | C | | -| 8\.13 | Session-Timeout AVP | C | | -| 8\.14 | User-Name AVP | C | | -| 8\.15 | Termination-Cause AVP | C | | -| 8\.16 | Origin-State-Id AVP | C | | -| 8\.17 | Session-Binding AVP | C | | -| 8\.18 | Session-Server-Failover AVP | C | | -| 8\.19 | Multi-Round-Time-Out AVP | C | | -| 8\.20 | Class AVP | C | | -| 8\.21 | Event-Timestamp AVP | C | | -| 9 | Accounting | — | Accounting-related messages and AVPs are defined in provided dictionaries. Their proper use is the user's responsibility. | -| 9\.1 | Server Directed Model | — | | -| 9\.2 | Protocol Messages | — | | -| 9\.3 | Accounting Application Extension and Requirements | — | | -| 9\.4 | Fault Resilience | — | | -| 9\.5 | Accounting Records | — | | -| 9\.6 | Correlation of Accounting Records | — | | -| 9\.7 | Accounting Command Codes | — | | -| 9\.7.1 | Accounting-Request | C | | -| 9\.7.2 | Accounting-Answer | C | | -| 9\.8 | Accounting AVPs | — | | -| 9\.8.1 | Accounting-Record-Type AVP | C | | -| 9\.8.2 | Acct-Interim-Interval AVP | C | | -| 9\.8.3 | Accounting-Record-Number AVP | C | | -| 9\.8.4 | Acct-Session-Id AVP | C | | -| 9\.8.5 | Acct-Multi-Session-Id AVP | C | | -| 9\.8.6 | Accounting-Sub-Session-Id AVP | C | | -| 9\.8.7 | Accounting-Realtime-Required AVP | C | | -| 10 | AVP Occurrence Tables | — | | -| 10\.1 | Base Protocol Command AVP Table | — | | -| 10\.2 | Accounting AVP Table | — | | -| 11 | IANA Considerations | — | | -| 11\.1 | AVP Header | — | | -| 11\.1.1 | AVP Codes | — | | -| 11\.1.2 | AVP Flags | — | | -| 11\.2 | Diameter Header | — | | -| 11\.2.1 | Command Codes | — | | -| 11\.2.2 | Command Flags | | | -| 11\.3 | AVP Values | — | | -| 11\.3.1 | Experimental-Result-Code AVP | — | | -| 11\.3.2 | Result-Code AVP Values | — | | -| 11\.3.3 | Accounting-Record-Type AVP Values | — | | -| 11\.3.4 | Termination-Cause AVP Values | — | | -| 11\.3.5 | Redirect-Host-Usage AVP Values | — | | -| 11\.3.6 | Session-Server-Failover AVP Values | — | | -| 11\.3.7 | Session-Binding AVP Values | — | | -| 11\.3.8 | Disconnect-Cause AVP Values | — | | -| 11\.3.9 | Auth-Request-Type AVP Values | — | | -| 11\.3.10 | Auth-Session-State AVP Values | — | | -| 11\.3.11 | Re-Auth-Request-Type AVP Values | — | | -| 11\.3.12 | Accounting-Realtime-Required AVP Values | — | | -| 11\.3.13 | Inband-Security-Id AVP (code 299) | — | | -| 11\.4 | \_diameters Service Name and Port Number Registration | — | | -| 11\.5 | SCTP Payload Protocol Identifiers | — | | -| 11\.6 | S-NAPTR Parameters | — | | -| 12 | Diameter Protocol-Related Configurable Parameters | — | | -| 13 | Security Considerations | PC | See 2.1.   IPsec is transparent to diameter. | -| 13\.1 | TLS/TCP and DTLS/SCTP Usage | PC | See 2.1. | -| 13\.2 | Peer-to-Peer Considerations | — | | -| 13\.3 | AVP Considerations | — | | -| 14 | References | — | | -| 14\.1 | Normative References | — | | -| 14\.2 | Informative References | — | | +| Section | Title | Compliance | Notes | +| -------- | ----------------------------------------------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 1 | Introduction | — | | +| 1\.1 | Diameter Protocol | — | | +| 1\.1.1 | Description of the Document Set | — | | +| 1\.1.2 | Conventions Used in This Document | — | | +| 1\.1.3 | Changes from RFC 3588 | — | It is possible to configure a 3588 dictionary in order to get 3588 semantics, where the differ from 6733. | +| 1\.2 | Terminology | — | | +| 1\.3 | Approach to Extensibility | — | The dictionary interface documented in [diameter_dict(4)](diameter_dict.md) provides extensibility, allowing the user to defined new AVPs, commands, and applications. Ready dictionaries are provided for the RFC 6733 common message, base accounting, and relay applications, as well as for RFC 7683, Diameter Overload Indicator Conveyance. | +| 1\.3.1 | Defining New AVP Values | — | | +| 1\.3.2 | Creating New AVPs | — | New AVPs can be defined using the dictionary interface. Both RFC data formats and extensions are supported. | +| 1\.3.3 | Creating New Commands | — | New commands can be defined using the dictionary interface. | +| 1\.3.4 | Creating New Diameter Applications | — | New applications can be defined using the dictionary interface. | +| 2 | Protocol Overview | — | Session state is the responsibility of the user.   The role of a Diameter node is determined by the user's implementation. | +| 2\.1 | Transport | PC | Ports are configured by the user: diameter places no restrictions.   The transport interface documented in `m:diameter_transport` allows the user to implement their own methods. Ready support is provided for TCP, TCP/TLS, and SCTP, but not DTLS/SCTP.   Multiple connections to the same peer is possible. ICMP messages are not interpreted. | +| 2\.1.1 | SCTP Guidelines | C | Unordered sending is configurable in `m:diameter_sctp`. There is no special handling of DPR/DPA: since a user that cares about pending answers should wait for them before initiating DPR.   A PPID can be configured with a a gen_sctp sctp_default_send_param option. | +| 2\.2 | Securing Diameter Messages | PC | DTLS is not supported by `m:diameter_sctp`. See also 2.1. | +| 2\.3 | Diameter Application Compliance | — | | +| 2\.4 | Application Identifiers | C | The user configures diameter with the identifiers to send at capabilities exchange, along with corresponding dictionaries defining the messages of the applications. | +| 2\.5 | Connections vs. Sessions | C | Connections are realized by configuring transport. Sessions are the responsibility of the user. | +| 2\.6 | Peer Table | PC | Routing is implemented by the user in callbacks documented in `m:diameter_app`. A peer table of the documented form is not exposed to the user. | +| 2\.7 | Routing Table | PC | See 2.6. A routing table of the documented form is not exposed to the user. | +| 2\.8 | Role of Diameter Agents | C | Most role-specific behaviour is implemented by the user. How a node advertises itself at capabilities exchange is determined by user configuration. | +| 2\.8.1 | Relay Agents | C | | +| 2\.8.2 | Proxy Agents | C | | +| 2\.8.3 | Redirect Agents | C | | +| 2\.8.4 | Translation Agents | C | | +| 2\.9 | Diameter Path Authorization | — | Authorization is the responsibility of the user. | +| 3 | Diameter Header | C | Hop-by-Hop and End-to-End Identifiers are set by diameter when sending outgoing requests. | +| 3\.1 | Command Codes | C | | +| 3\.2 | Command Code Format Specification | C | Commands are defined as CCF specifications in dictionary files. | +| 3\.3 | Diameter Command Naming Conventions | — | | +| 4 | Diameter AVPs | C | Any required padding is added by diameter when encoding outgoing messages. | +| 4\.1 | AVP Header | C | | +| 4\.1.1 | Optional Header Elements | C | | +| 4\.2 | Basic AVP Data Formats | C | | +| 4\.3 | Derived AVP Data Formats | C | Arbitrary derived data formats are supported by the dictionary interface. | +| 4\.3.1 | Common Derived AVP Data Formats | C | Beware that RFC 6733 changed the DiameterURI transport/port defaults specified in RFC3588. Relying on the defaults can result in interoperability problems. | +| 4\.4 | Grouped AVP Values | C | The M-bit on a component AVP of a Grouped AVP that does not set M is ignored: such AVPs are not regarded as erroneous at decode.   Grouped AVPs are defined as CCF specifications in dictionary files. | +| 4\.4.1 | Example AVP with a Grouped Data Type | — | | +| 4\.5 | Diameter Base Protocol AVPs | C | The base AVPs are defined in the common dictionary provided by diameter. There are common dictionaries for both RFC 3588 and RFC 6733 since the latter made changes to both syntax and semantics. | +| 5 | Diameter Peers | — | | +| 5\.1 | Peer Connections | PC | A peer's DiameterIdentity is not required when initiating a connection: the identify is received at capabilities exchange, at which time the connection can be rejected if the identity is objectionable.   The number of connections established depends on the user's configuration. Multiple connections per peer is possible. | +| 5\.2 | Diameter Peer Discovery | NC | No form of peer discovery is implemented. The user can implement this independently of diameter if required. | +| 5\.3 | Capabilities Exchange | C | All supported applications are sent in CEA. The user can reject an incoming CER or CEA in a configured callback.   Both transport security at connection establishment and negotiated via an Inband-Security AVP are supported. | +| 5\.3.1 | Capabilities-Exchange-Request | C | CER is sent and received by diameter. | +| 5\.3.2 | Capabilities-Exchange-Answer | C | CEA is sent and received by diameter. | +| 5\.3.3 | Vendor-Id AVP | C | | +| 5\.3.4 | Firmware-Revision AVP | C | | +| 5\.3.5 | Host-IP-Address AVP | C | | +| 5\.3.6 | Supported-Vendor-Id AVP | C | | +| 5\.3.7 | Product-Name AVP | C | | +| 5\.4 | Disconnecting Peer Connections | C | DPA will not be answered with error: a peer that wants to a avoid a race can wait for pending answers before sending DPR. | +| 5\.4.1 | Disconnect-Peer-Request | C | DPR is sent by diameter in response to configuration changes requiring a connection to be broken. The user can also send DPR. | +| 5\.4.2 | Disconnect-Peer-Answer | C | DPR is answered by diameter. | +| 5\.4.3 | Disconnect-Cause AVP | C | | +| 5\.5 | Transport Failure Detection | — | | +| 5\.5.1 | Device-Watchdog-Request | C | DWR is sent and received by diameter. Callbacks notify the user of transitions into and out of the OKAY state. | +| 5\.5.2 | Device-Watchdog-Answer | C | DWA is sent and received by diameter. | +| 5\.5.3 | Transport Failure Algorithm | C | | +| 5\.5.4 | Failover and Failback Procedures | C | | +| 5\.6 | Peer State Machine | PC | The election process is modified as described in 5.6.4. | +| 5\.6.1 | Incoming Connections | C | | +| 5\.6.2 | Events | — | | +| 5\.6.3 | Actions | — | | +| 5\.6.4 | The Election Process | PC | As documented, the election assumes knowledge of a peer's DiameterIdentity when initiating a connection, which diameter doesn't require. Connections will be accepted if configuration allows multiple connections per peer to be established or there is no existing connection. Note that the election process is only applicable when multiple connections per peer is disallowed. | +| 6 | Diameter Message Processing | — | | +| 6\.1 | Diameter Request Routing Overview | — | Routing is performed by the user. A callback from diameter provides a list of available suitable peer connections. | +| 6\.1.1 | Originating a Request | C | Requests are constructed by the user; diameter sets header fields as defined in the relevant dictionary. | +| 6\.1.2 | Sending a Request | C | | +| 6\.1.3 | Receiving Requests | C | Loops are detected by diameter when the return value of a request callback asks that a request be forwarded. Loop detection in other cases is the responsibility of the user. | +| 6\.1.4 | Processing Local Requests | C | The user decides whether or not to process a request locally in the request callback from diameter. | +| 6\.1.5 | Request Forwarding | PC | See 2.6. | +| 6\.1.6 | Request Routing | PC | See 2.7. | +| 6\.1.7 | Predictive Loop Avoidance | C | See 6.1.3. | +| 6\.1.8 | Redirecting Requests | PC | See 2.6. | +| 6\.1.9 | Relaying and Proxying Requests | C | A Route-Record AVP is appended by diameter when the return value of a request callback asks that a request be forwarded. Appending the AVP in other cases is the responsibility of the user. | +| 6\.2 | Diameter Answer Processing | C | Answer message are constructed by the user, except in the case of some protocol errors, in which case the procedures are followed. | +| 6\.2.1 | Processing Received Answers | C | Answers with an unknown Hop-by-Hop Identifier are discarded. | +| 6\.2.2 | Relaying and Proxying Answers | — | Modifying answers is the responsibility of the user in callbacks from diameter. | +| 6\.3 | Origin-Host AVP | C | The order of AVPs in an encoded message is determined by the CCF of the message in question.   AVPs defined in the RFC are defined in dictionaries provided by diameter. Their proper use in application messages is the responsibility of the user. | +| 6\.4 | Origin-Realm AVP | C | | +| 6\.5 | Destination-Host AVP | C | | +| 6\.6 | Destination-Realm AVP | C | | +| 6\.7 | Routing AVPs | — | | +| 6\.7.1 | Route-Record AVP | C | | +| 6\.7.2 | Proxy-Info AVP | C | | +| 6\.7.3 | Proxy-Host AVP | C | | +| 6\.7.4 | Proxy-State AVP | C | | +| 6\.8 | Auth-Application-Id AVP | C | | +| 6\.9 | Acct-Application-Id AVP | C | | +| 6\.10 | Inband-Security-Id AVP | C | See 2.1. | +| 6\.11 | Vendor-Specific-Application-Id AVP | C | Note that the CCF of this AVP is not the same as in RFC 3588. | +| 6\.12 | Redirect-Host AVP | C | | +| 6\.13 | Redirect-Host-Usage AVP | C | | +| 6\.14 | Redirect-Max-Cache-Time AVP | C | | +| 7 | Error Handling | C | Answers are formulated by the user in most cases. Answers setting the E-bit can be sent by diameter itself in response to a request that cannot be handled by the user. | +| 7\.1 | Result-Code AVP | C | | +| 7\.1.1 | Informational | C | | +| 7\.1.2 | Success | C | | +| 7\.1.3 | Protocol Errors | C | Result codes 3001, 3002, 3005, and 3007 can be sent in answers formulated by diameter, if configured to do so. | +| 7\.1.4 | Transient Failures | C | Result code 4003 is sent in CEA if there is an existing connection to the peer in question and configuration does not allow more than one. | +| 7\.1.5 | Permanent Failures | C | Message reception detects 5001, 5004, 5005, 5008, 5009, 5010, 5011, 5014, 5015, and 5017 errors. It ignores 5013 errors at the admonition of sections 3 and 4.1.   Note that RFC 3588 did not allow 5xxx result codes in answers setting the E-bit, while RFC 6733 does. This is a potential interoperability problem since the Diameter protocol version has not changed. | +| 7\.2 | Error Bit | C | | +| 7\.3 | Error-Message AVP | C | The user can include this AVP as required. | +| 7\.4 | Error-Reporting-Host AVP | C | The user can include this AVP as required. | +| 7\.5 | Failed-AVP AVP | C | The user constructs application-specific messages, but diameter provides failed AVPs in message callbacks. Failed component AVPs are grouped within the relevant Grouped AVPs. | +| 7\.6 | Experimental-Result AVP | C | | +| 7\.7 | Experimental-Result-Code AVP | C | | +| 8 | Diameter User Sessions | — | Authorization and accounting AVPs are defined in provided dictionaries. Their proper use is the responsibility of the user. | +| 8\.1 | Authorization Session State Machine | — | Authorization is the responsibility of the user: diameter does not implement this state machine. | +| 8\.2 | Accounting Session State Machine | — | Accounting is the responsibility of the user: diameter does not implement this state machine. | +| 8\.3 | Server-Initiated Re-Auth | — | | +| 8\.3.1 | Re-Auth-Request | C | | +| 8\.3.2 | Re-Auth-Answer | C | | +| 8\.4 | Session Termination | — | Session-related messages and AVPs are defined in provided dictionaries. Their proper use is the user's responsibility. | +| 8\.4.1 | Session-Termination-Request | C | | +| 8\.4.2 | Session-Termination-Answer | C | | +| 8\.5 | Aborting a Session | — | Session-related messages and AVPs are defined in provided dictionaries. Their proper use is the user's responsibility. | +| 8\.5.1 | Abort-Session-Request | C | | +| 8\.5.2 | Abort-Session-Answer | C | | +| 8\.6 | Inferring Session Termination from Origin-State-Id | — | Session-related messages and AVPs are defined in provided dictionaries. Their proper use is the user's responsibility. | +| 8\.7 | Auth-Request-Type AVP | C | | +| 8\.8 | Session-Id AVP | C | | +| 8\.9 | Authorization-Lifetime AVP | C | | +| 8\.10 | Auth-Grace-Period AVP | C | | +| 8\.11 | Auth-Session-State AVP | C | | +| 8\.12 | Re-Auth-Request-Type AVP | C | | +| 8\.13 | Session-Timeout AVP | C | | +| 8\.14 | User-Name AVP | C | | +| 8\.15 | Termination-Cause AVP | C | | +| 8\.16 | Origin-State-Id AVP | C | | +| 8\.17 | Session-Binding AVP | C | | +| 8\.18 | Session-Server-Failover AVP | C | | +| 8\.19 | Multi-Round-Time-Out AVP | C | | +| 8\.20 | Class AVP | C | | +| 8\.21 | Event-Timestamp AVP | C | | +| 9 | Accounting | — | Accounting-related messages and AVPs are defined in provided dictionaries. Their proper use is the user's responsibility. | +| 9\.1 | Server Directed Model | — | | +| 9\.2 | Protocol Messages | — | | +| 9\.3 | Accounting Application Extension and Requirements | — | | +| 9\.4 | Fault Resilience | — | | +| 9\.5 | Accounting Records | — | | +| 9\.6 | Correlation of Accounting Records | — | | +| 9\.7 | Accounting Command Codes | — | | +| 9\.7.1 | Accounting-Request | C | | +| 9\.7.2 | Accounting-Answer | C | | +| 9\.8 | Accounting AVPs | — | | +| 9\.8.1 | Accounting-Record-Type AVP | C | | +| 9\.8.2 | Acct-Interim-Interval AVP | C | | +| 9\.8.3 | Accounting-Record-Number AVP | C | | +| 9\.8.4 | Acct-Session-Id AVP | C | | +| 9\.8.5 | Acct-Multi-Session-Id AVP | C | | +| 9\.8.6 | Accounting-Sub-Session-Id AVP | C | | +| 9\.8.7 | Accounting-Realtime-Required AVP | C | | +| 10 | AVP Occurrence Tables | — | | +| 10\.1 | Base Protocol Command AVP Table | — | | +| 10\.2 | Accounting AVP Table | — | | +| 11 | IANA Considerations | — | | +| 11\.1 | AVP Header | — | | +| 11\.1.1 | AVP Codes | — | | +| 11\.1.2 | AVP Flags | — | | +| 11\.2 | Diameter Header | — | | +| 11\.2.1 | Command Codes | — | | +| 11\.2.2 | Command Flags | | | +| 11\.3 | AVP Values | — | | +| 11\.3.1 | Experimental-Result-Code AVP | — | | +| 11\.3.2 | Result-Code AVP Values | — | | +| 11\.3.3 | Accounting-Record-Type AVP Values | — | | +| 11\.3.4 | Termination-Cause AVP Values | — | | +| 11\.3.5 | Redirect-Host-Usage AVP Values | — | | +| 11\.3.6 | Session-Server-Failover AVP Values | — | | +| 11\.3.7 | Session-Binding AVP Values | — | | +| 11\.3.8 | Disconnect-Cause AVP Values | — | | +| 11\.3.9 | Auth-Request-Type AVP Values | — | | +| 11\.3.10 | Auth-Session-State AVP Values | — | | +| 11\.3.11 | Re-Auth-Request-Type AVP Values | — | | +| 11\.3.12 | Accounting-Realtime-Required AVP Values | — | | +| 11\.3.13 | Inband-Security-Id AVP (code 299) | — | | +| 11\.4 | \_diameters Service Name and Port Number Registration | — | | +| 11\.5 | SCTP Payload Protocol Identifiers | — | | +| 11\.6 | S-NAPTR Parameters | — | | +| 12 | Diameter Protocol-Related Configurable Parameters | — | | +| 13 | Security Considerations | PC | See 2.1.   IPsec is transparent to diameter. | +| 13\.1 | TLS/TCP and DTLS/SCTP Usage | PC | See 2.1. | +| 13\.2 | Peer-to-Peer Considerations | — | | +| 13\.3 | AVP Considerations | — | | +| 14 | References | — | | +| 14\.1 | Normative References | — | | +| 14\.2 | Informative References | — | | _Table: RFC 6733 Compliance_ diff --git a/lib/edoc/doc/guides/chapter.md b/lib/edoc/doc/guides/chapter.md index 42eea97880c7..45353d8fcce0 100644 --- a/lib/edoc/doc/guides/chapter.md +++ b/lib/edoc/doc/guides/chapter.md @@ -452,17 +452,17 @@ In several contexts (`@see` tags, `@link` macros, etc.), EDoc lets you refer to the generated documentation for modules, functions, datatypes, and applications, using a simple and compact syntax. The possible formats for references are: -| _Reference syntax_ | _Example_ | _Scope_ | -| ------------------------------------- | ----------------------------------------------- | ------------- | -| `Module` | `m:edoc_run`, `erl.lang.list` | Global | -| `Function/Arity` | `file/2` | Within module | -| `Module:Function/Arity` | `edoc:application/2` | Global | -| `Type()` | `filename()` | Within module | -| `Module:Type()` | [edoc:edoc_module()](`t:edoc:edoc_module/0`) | Global | -| `//Application` | [edoc](index.html) | Global | -| `//Application/Module` | `m:edoc_doclet` | Global | -| `//Application/Module:Function/Arity` | `edoc_run:file/1` | Global | -| `//Application/Module:Type()` | [edoc:edoc_module()](`t:edoc:edoc_module/0`) | Global | +| Reference syntax | Example | Scope | +| ------------------------------------- | -------------------------------------------- | ------------- | +| `Module` | `m:edoc_run`, `erl.lang.list` | Global | +| `Function/Arity` | `file/2` | Within module | +| `Module:Function/Arity` | `edoc:application/2` | Global | +| `Type()` | `filename()` | Within module | +| `Module:Type()` | [edoc:edoc_module()](`t:edoc:edoc_module/0`) | Global | +| `//Application` | [edoc](index.html) | Global | +| `//Application/Module` | `m:edoc_doclet` | Global | +| `//Application/Module:Function/Arity` | `edoc_run:file/1` | Global | +| `//Application/Module:Type()` | [edoc:edoc_module()](`t:edoc:edoc_module/0`) | Global | _Table: reference syntax_ diff --git a/lib/kernel/doc/guides/socket_usage.md b/lib/kernel/doc/guides/socket_usage.md index d6b97fa80ebc..0a346d5bccb0 100644 --- a/lib/kernel/doc/guides/socket_usage.md +++ b/lib/kernel/doc/guides/socket_usage.md @@ -84,7 +84,7 @@ The general form of the 'socket' message is: Where the format of `Info` is a function of `Tag`: -| _Tag_ | _Info value type_ | +| Tag | Info value type | | ---------- | ----------------------------------------- | | select | select_handle() | | completion | \{completion_handle(), CompletionStatus\} | @@ -374,153 +374,153 @@ which_family(Addr) when is_tuple(Addr) andalso (tuple_size(Addr) =:= 8) -> Options for level `otp`: -| _Option Name_ | _Value Type_ | _Set_ | _Get_ | _Other Requirements and comments_ | -| ------------------- | ------------------------------------------------------------- | ----- | ----- | ---------------------------------------------------------------------------------------------------------------------------------------------- | -| assoc_id | integer() | no | yes | type = seqpacket, protocol = sctp, is an association | -| debug | boolean() | yes | yes | none | -| iow | boolean() | yes | yes | none | -| controlling_process | pid() | yes | yes | none | -| rcvbuf | default \| pos_integer() \| \{pos_integer(), pos_ineteger()\} | yes | yes | The tuple format is _not_ allowed on Windows. 'default' only valid for set. The tuple form is only valid for type 'stream' and protocol 'tcp'. | -| rcvctrlbuf | default \| pos_integer() | yes | yes | default only valid for set | -| sndctrlbuf | default \| pos_integer() | yes | yes | default only valid for set | -| fd | integer() | no | yes | none | -| use_registry | boolean() | no | yes | the value is set when the socket is created, by a call to [`open/2`](`socket:open/2`) or [`open/4`](`socket:open/4`). | +| Option Name | Value Type | Set | Get | Other Requirements and comments | +| ------------------- | ------------------------------------------------------------- | --- | --- | ---------------------------------------------------------------------------------------------------------------------------------------------- | +| assoc_id | integer() | no | yes | type = seqpacket, protocol = sctp, is an association | +| debug | boolean() | yes | yes | none | +| iow | boolean() | yes | yes | none | +| controlling_process | pid() | yes | yes | none | +| rcvbuf | default \| pos_integer() \| \{pos_integer(), pos_ineteger()\} | yes | yes | The tuple format is _not_ allowed on Windows. 'default' only valid for set. The tuple form is only valid for type 'stream' and protocol 'tcp'. | +| rcvctrlbuf | default \| pos_integer() | yes | yes | default only valid for set | +| sndctrlbuf | default \| pos_integer() | yes | yes | default only valid for set | +| fd | integer() | no | yes | none | +| use_registry | boolean() | no | yes | the value is set when the socket is created, by a call to [`open/2`](`socket:open/2`) or [`open/4`](`socket:open/4`). | _Table: option levels_ Options for level `socket`: -| _Option Name_ | _Value Type_ | _Set_ | _Get_ | _Other Requirements and comments_ | -| ---------------- | ----------------- | ----- | ----- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| acceptconn | boolean() | no | yes | none | -| bindtodevice | string() | yes | yes | Before Linux 3.8, this socket option could be set, but not get. Only works for some socket types (e.g. `inet`). If empty value is set, the binding is removed. | -| broadcast | boolean() | yes | yes | type = dgram | -| bsp_state | map() | no | yes | Windows only | -| debug | integer() | yes | yes | may require admin capability | -| domain | domain() | no | yes | _Not_ on FreeBSD (for instance) | -| dontroute | boolean() | yes | yes | none | -| exclusiveaddruse | boolean() | yes | yes | Windows only | -| keepalive | boolean() | yes | yes | none | -| linger | abort \| linger() | yes | yes | none | -| maxdg | integer() | no | yes | Windows only | -| max_msg_size | integer() | no | yes | Windows only | -| oobinline | boolean() | yes | yes | none | -| peek_off | integer() | yes | yes | domain = local (unix). Currently disabled due to a possible infinite loop when calling recv(\[peek]) the second time. | -| priority | integer() | yes | yes | none | -| protocol | protocol() | no | yes | _Not_ on (some) Darwin (for instance) | -| rcvbuf | non_neg_integer() | yes | yes | none | -| rcvlowat | non_neg_integer() | yes | yes | none | -| rcvtimeo | timeval() | yes | yes | This option is not normally supported (see why below). OTP has to be explicitly built with the `--enable-esock-rcvsndtime` configure option for this to be available. Since our implementation is _nonblocking_, its unknown if and how this option works, or even if it may cause malfunctions. Therefore, we do not recommend setting this option. Instead, use the `Timeout` argument to, for instance, the [`recv/3`](`socket:recv/3`) function. | -| reuseaddr | boolean() | yes | yes | none | -| reuseport | boolean() | yes | yes | domain = inet \| inet6 | -| sndbuf | non_neg_integer() | yes | yes | none | -| sndlowat | non_neg_integer() | yes | yes | not changeable on Linux | -| sndtimeo | timeval() | yes | yes | This option is not normally supported (see why below). OTP has to be explicitly built with the `--enable-esock-rcvsndtime` configure option for this to be available. Since our implementation is _nonblocking_, its unknown if and how this option works, or even if it may cause malfunctions. Therefore, we do not recommend setting this option. Instead, use the `Timeout` argument to, for instance, the [`send/3`](`socket:send/3`) function. | -| timestamp | boolean() | yes | yes | none | -| type | type() | no | yes | none | +| Option Name | Value Type | Set | Get | Other Requirements and comments | +| ---------------- | ----------------- | --- | --- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| acceptconn | boolean() | no | yes | none | +| bindtodevice | string() | yes | yes | Before Linux 3.8, this socket option could be set, but not get. Only works for some socket types (e.g. `inet`). If empty value is set, the binding is removed. | +| broadcast | boolean() | yes | yes | type = dgram | +| bsp_state | map() | no | yes | Windows only | +| debug | integer() | yes | yes | may require admin capability | +| domain | domain() | no | yes | _Not_ on FreeBSD (for instance) | +| dontroute | boolean() | yes | yes | none | +| exclusiveaddruse | boolean() | yes | yes | Windows only | +| keepalive | boolean() | yes | yes | none | +| linger | abort \| linger() | yes | yes | none | +| maxdg | integer() | no | yes | Windows only | +| max_msg_size | integer() | no | yes | Windows only | +| oobinline | boolean() | yes | yes | none | +| peek_off | integer() | yes | yes | domain = local (unix). Currently disabled due to a possible infinite loop when calling recv(\[peek]) the second time. | +| priority | integer() | yes | yes | none | +| protocol | protocol() | no | yes | _Not_ on (some) Darwin (for instance) | +| rcvbuf | non_neg_integer() | yes | yes | none | +| rcvlowat | non_neg_integer() | yes | yes | none | +| rcvtimeo | timeval() | yes | yes | This option is not normally supported (see why below). OTP has to be explicitly built with the `--enable-esock-rcvsndtime` configure option for this to be available. Since our implementation is _nonblocking_, its unknown if and how this option works, or even if it may cause malfunctions. Therefore, we do not recommend setting this option. Instead, use the `Timeout` argument to, for instance, the [`recv/3`](`socket:recv/3`) function. | +| reuseaddr | boolean() | yes | yes | none | +| reuseport | boolean() | yes | yes | domain = inet \| inet6 | +| sndbuf | non_neg_integer() | yes | yes | none | +| sndlowat | non_neg_integer() | yes | yes | not changeable on Linux | +| sndtimeo | timeval() | yes | yes | This option is not normally supported (see why below). OTP has to be explicitly built with the `--enable-esock-rcvsndtime` configure option for this to be available. Since our implementation is _nonblocking_, its unknown if and how this option works, or even if it may cause malfunctions. Therefore, we do not recommend setting this option. Instead, use the `Timeout` argument to, for instance, the [`send/3`](`socket:send/3`) function. | +| timestamp | boolean() | yes | yes | none | +| type | type() | no | yes | none | _Table: socket options_ Options for level `ip`: -| _Option Name_ | _Value Type_ | _Set_ | _Get_ | _Other Requirements and comments_ | -| ---------------------- | --------------------- | ----- | ----- | ---------------------------------------------------------- | -| add_membership | ip_mreq() | yes | no | none | -| add_source_membership | ip_mreq_source() | yes | no | none | -| block_source | ip_mreq_source() | yes | no | none | -| drop_membership | ip_mreq() | yes | no | none | -| drop_source_membership | ip_mreq_source() | yes | no | none | -| freebind | boolean() | yes | yes | none | -| hdrincl | boolean() | yes | yes | type = raw | -| minttl | integer() | yes | yes | type = raw | -| msfilter | null \| ip_msfilter() | yes | no | none | -| mtu | integer() | no | yes | type = raw | -| mtu_discover | ip_pmtudisc() | yes | yes | none | -| multicast_all | boolean() | yes | yes | none | -| multicast_if | any \| ip4_address() | yes | yes | none | -| multicast_loop | boolean() | yes | yes | none | -| multicast_ttl | uint8() | yes | yes | none | -| nodefrag | boolean() | yes | yes | type = raw | -| pktinfo | boolean() | yes | yes | type = dgram | -| recvdstaddr | boolean() | yes | yes | type = dgram | -| recverr | boolean() | yes | yes | none | -| recvif | boolean() | yes | yes | type = dgram \| raw | -| recvopts | boolean() | yes | yes | type =/= stream | -| recvorigdstaddr | boolean() | yes | yes | none | -| recvttl | boolean() | yes | yes | type =/= stream | -| retopts | boolean() | yes | yes | type =/= stream | -| router_alert | integer() | yes | yes | type = raw | -| sendsrcaddr | boolean() | yes | yes | none | -| tos | ip_tos() | yes | yes | some high-priority levels may require superuser capability | -| transparent | boolean() | yes | yes | requires admin capability | -| ttl | integer() | yes | yes | none | -| unblock_source | ip_mreq_source() | yes | no | none | +| Option Name | Value Type | Set | Get | Other Requirements and comments | +| ---------------------- | --------------------- | --- | --- | ---------------------------------------------------------- | +| add_membership | ip_mreq() | yes | no | none | +| add_source_membership | ip_mreq_source() | yes | no | none | +| block_source | ip_mreq_source() | yes | no | none | +| drop_membership | ip_mreq() | yes | no | none | +| drop_source_membership | ip_mreq_source() | yes | no | none | +| freebind | boolean() | yes | yes | none | +| hdrincl | boolean() | yes | yes | type = raw | +| minttl | integer() | yes | yes | type = raw | +| msfilter | null \| ip_msfilter() | yes | no | none | +| mtu | integer() | no | yes | type = raw | +| mtu_discover | ip_pmtudisc() | yes | yes | none | +| multicast_all | boolean() | yes | yes | none | +| multicast_if | any \| ip4_address() | yes | yes | none | +| multicast_loop | boolean() | yes | yes | none | +| multicast_ttl | uint8() | yes | yes | none | +| nodefrag | boolean() | yes | yes | type = raw | +| pktinfo | boolean() | yes | yes | type = dgram | +| recvdstaddr | boolean() | yes | yes | type = dgram | +| recverr | boolean() | yes | yes | none | +| recvif | boolean() | yes | yes | type = dgram \| raw | +| recvopts | boolean() | yes | yes | type =/= stream | +| recvorigdstaddr | boolean() | yes | yes | none | +| recvttl | boolean() | yes | yes | type =/= stream | +| retopts | boolean() | yes | yes | type =/= stream | +| router_alert | integer() | yes | yes | type = raw | +| sendsrcaddr | boolean() | yes | yes | none | +| tos | ip_tos() | yes | yes | some high-priority levels may require superuser capability | +| transparent | boolean() | yes | yes | requires admin capability | +| ttl | integer() | yes | yes | none | +| unblock_source | ip_mreq_source() | yes | no | none | _Table: ip options_ Options for level `ipv6`: -| _Option Name_ | _Value Type_ | _Set_ | _Get_ | _Other Requirements and comments_ | -| ---------------------- | ------------------ | ----- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| addrform | inet | yes | no | allowed only for IPv6 sockets that are connected and bound to a v4-mapped-on-v6 address | -| add_membership | ipv6_mreq() | yes | no | none | -| authhdr | boolean() | yes | yes | type = dgram \| raw, obsolete? | -| drop_membership | ipv6_mreq() | yes | no | none | -| dstopts | boolean() | yes | yes | type = dgram \| raw, requires superuser privileges to update | -| flowinfo | boolean() | yes | yes | type = dgram \| raw, requires superuser privileges to update | -| hoplimit | boolean() | yes | yes | type = dgram \| raw. On some platforms (e.g. FreeBSD) is used to set in order to get `hoplimit` as a control message heeader. On others (e.g. Linux), `recvhoplimit` is set in order to get `hoplimit`. | -| hopopts | boolean() | yes | yes | type = dgram \| raw, requires superuser privileges to update | -| mtu | boolean() | yes | yes | Get: Only after the socket has been connected | -| mtu_discover | ipv6_pmtudisc() | yes | yes | none | -| multicast_hops | default \| uint8() | yes | yes | none | -| multicast_if | integer() | yes | yes | type = dgram \| raw | -| multicast_loop | boolean() | yes | yes | none | -| recverr | boolean() | yes | yes | none | -| recvhoplimit | boolean() | yes | yes | type = dgram \| raw. On some platforms (e.g. Linux), `recvhoplimit` is set in order to get `hoplimit` | -| recvpktinfo \| pktinfo | boolean() | yes | yes | type = dgram \| raw. On some platforms (e.g. FreeBSD) is used to set in order to get `hoplimit` as a control message heeader. On others (e.g. Linux), `recvhoplimit` is set in order to get `hoplimit`. | -| recvtclass | boolean() | yes | yes | type = dgram \| raw. On some platforms is used to set (=true) in order to get the `tclass` control message heeader. On others, `tclass` is set in order to get `tclass` control message heeader. | -| router_alert | integer() | yes | yes | type = raw | -| rthdr | boolean() | yes | yes | type = dgram \| raw, requires superuser privileges to update | -| tclass | integer() | yes | yes | Set the traffic class associated with outgoing packets. RFC3542. | -| unicast_hops | default \| uint8() | yes | yes | none | -| v6only | boolean() | yes | no | none | +| Option Name | Value Type | Set | Get | Other Requirements and comments | +| ---------------------- | ------------------ | --- | --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| addrform | inet | yes | no | allowed only for IPv6 sockets that are connected and bound to a v4-mapped-on-v6 address | +| add_membership | ipv6_mreq() | yes | no | none | +| authhdr | boolean() | yes | yes | type = dgram \| raw, obsolete? | +| drop_membership | ipv6_mreq() | yes | no | none | +| dstopts | boolean() | yes | yes | type = dgram \| raw, requires superuser privileges to update | +| flowinfo | boolean() | yes | yes | type = dgram \| raw, requires superuser privileges to update | +| hoplimit | boolean() | yes | yes | type = dgram \| raw. On some platforms (e.g. FreeBSD) is used to set in order to get `hoplimit` as a control message heeader. On others (e.g. Linux), `recvhoplimit` is set in order to get `hoplimit`. | +| hopopts | boolean() | yes | yes | type = dgram \| raw, requires superuser privileges to update | +| mtu | boolean() | yes | yes | Get: Only after the socket has been connected | +| mtu_discover | ipv6_pmtudisc() | yes | yes | none | +| multicast_hops | default \| uint8() | yes | yes | none | +| multicast_if | integer() | yes | yes | type = dgram \| raw | +| multicast_loop | boolean() | yes | yes | none | +| recverr | boolean() | yes | yes | none | +| recvhoplimit | boolean() | yes | yes | type = dgram \| raw. On some platforms (e.g. Linux), `recvhoplimit` is set in order to get `hoplimit` | +| recvpktinfo \| pktinfo | boolean() | yes | yes | type = dgram \| raw. On some platforms (e.g. FreeBSD) is used to set in order to get `hoplimit` as a control message heeader. On others (e.g. Linux), `recvhoplimit` is set in order to get `hoplimit`. | +| recvtclass | boolean() | yes | yes | type = dgram \| raw. On some platforms is used to set (=true) in order to get the `tclass` control message heeader. On others, `tclass` is set in order to get `tclass` control message heeader. | +| router_alert | integer() | yes | yes | type = raw | +| rthdr | boolean() | yes | yes | type = dgram \| raw, requires superuser privileges to update | +| tclass | integer() | yes | yes | Set the traffic class associated with outgoing packets. RFC3542. | +| unicast_hops | default \| uint8() | yes | yes | none | +| v6only | boolean() | yes | no | none | _Table: ipv6 options_ Options for level `tcp`: -| _Option Name_ | _Value Type_ | _Set_ | _Get_ | _Other Requirements and comments_ | -| ------------- | ------------ | ----- | ----- | -------------------------------------------------------------------------------------------------------- | -| congestion | string() | yes | yes | none | -| cork | boolean() | yes | yes | 'nopush' one some platforms (FreeBSD) | -| keepcnt | integer() | yes | yes | On Windows (at least), it is illegal to set to a value greater than 255. | -| keepidle | integer() | yes | yes | none | -| keepintvl | integer() | yes | yes | none | -| maxseg | integer() | yes | yes | Set not allowed on all platforms. | -| nodelay | boolean() | yes | yes | none | -| nopush | boolean() | yes | yes | 'cork' on some platforms (Linux). On Darwin this has a different meaning than on, for instance, FreeBSD. | +| Option Name | Value Type | Set | Get | Other Requirements and comments | +| ----------- | ---------- | --- | --- | -------------------------------------------------------------------------------------------------------- | +| congestion | string() | yes | yes | none | +| cork | boolean() | yes | yes | 'nopush' one some platforms (FreeBSD) | +| keepcnt | integer() | yes | yes | On Windows (at least), it is illegal to set to a value greater than 255. | +| keepidle | integer() | yes | yes | none | +| keepintvl | integer() | yes | yes | none | +| maxseg | integer() | yes | yes | Set not allowed on all platforms. | +| nodelay | boolean() | yes | yes | none | +| nopush | boolean() | yes | yes | 'cork' on some platforms (Linux). On Darwin this has a different meaning than on, for instance, FreeBSD. | _Table: tcp options_ Options for level `udp`: -| _Option Name_ | _Value Type_ | _Set_ | _Get_ | _Other Requirements and comments_ | -| ------------- | ------------ | ----- | ----- | --------------------------------- | -| cork | boolean() | yes | yes | none | +| Option Name | Value Type | Set | Get | Other Requirements and comments | +| ----------- | ---------- | --- | --- | ------------------------------- | +| cork | boolean() | yes | yes | none | _Table: udp options_ Options for level `sctp`: -| _Option Name_ | _Value Type_ | _Set_ | _Get_ | _Other Requirements and comments_ | -| ----------------- | ---------------------- | ----- | ----- | --------------------------------- | -| associnfo | sctp_assocparams() | yes | yes | none | -| autoclose | non_neg_integer() | yes | yes | none | -| disable_fragments | boolean() | yes | yes | none | -| events | sctp_event_subscribe() | yes | no | none | -| initmsg | sctp_initmsg() | yes | yes | none | -| maxseg | non_neg_integer() | yes | yes | none | -| nodelay | boolean() | yes | yes | none | -| rtoinfo | sctp_rtoinfo() | yes | yes | none | +| Option Name | Value Type | Set | Get | Other Requirements and comments | +| ----------------- | ---------------------- | --- | --- | ------------------------------- | +| associnfo | sctp_assocparams() | yes | yes | none | +| autoclose | non_neg_integer() | yes | yes | none | +| disable_fragments | boolean() | yes | yes | none | +| events | sctp_event_subscribe() | yes | no | none | +| initmsg | sctp_initmsg() | yes | yes | none | +| maxseg | non_neg_integer() | yes | yes | none | +| nodelay | boolean() | yes | yes | none | +| rtoinfo | sctp_rtoinfo() | yes | yes | none | _Table: sctp options_ diff --git a/lib/megaco/doc/guides/megaco_performance.md b/lib/megaco/doc/guides/megaco_performance.md index 11ad145c47dd..48cce0c93625 100644 --- a/lib/megaco/doc/guides/megaco_performance.md +++ b/lib/megaco/doc/guides/megaco_performance.md @@ -32,20 +32,20 @@ We have made four different measurements of our Erlang/OTP implementation of the Megaco/H.248 protocol stack, in order to compare our different encoders/decoders. The result of each one is summarized in the table below. -| _Codec and config_ | _Size_ | _Encode_ | _Decode_ | _Total_ | -| ---------------------------------------- | ------ | -------- | -------- | ------- | -| pretty | 336 | 5 | 12 | 17 | -| pretty \[flex] | 336 | 5 | 11 | 16 | -| compact | 181 | 4 | 10 | 14 | -| compact \[flex] | 181 | 4 | 9 | 13 | -| per bin | 91 | 6 | 6 | 12 | -| per bin \[native] | 91 | 4 | 3 | 7 | -| ber bin | 165 | 6 | 6 | 12 | -| ber bin \[native] | 165 | 4 | 3 | 7 | -| erl_dist | 875 | 2 | 5 | 7 | -| erl_dist \[megaco_compressed] | 405 | 1 | 2 | 3 | -| erl_dist \[compressed] | 345 | 15 | 9 | 24 | -| erl_dist \[megaco_compressed,compressed] | 200 | 11 | 4 | 15 | +| Codec and config | Size | Encode | Decode | Total | +| ---------------------------------------- | ---- | ------ | ------ | ----- | +| pretty | 336 | 5 | 12 | 17 | +| pretty \[flex] | 336 | 5 | 11 | 16 | +| compact | 181 | 4 | 10 | 14 | +| compact \[flex] | 181 | 4 | 9 | 13 | +| per bin | 91 | 6 | 6 | 12 | +| per bin \[native] | 91 | 4 | 3 | 7 | +| ber bin | 165 | 6 | 6 | 12 | +| ber bin \[native] | 165 | 4 | 3 | 7 | +| erl_dist | 875 | 2 | 5 | 7 | +| erl_dist \[megaco_compressed] | 405 | 1 | 2 | 3 | +| erl_dist \[compressed] | 345 | 15 | 9 | 24 | +| erl_dist \[megaco_compressed,compressed] | 200 | 11 | 4 | 15 | _Table: Codec performance_ diff --git a/lib/public_key/doc/guides/public_key_records.md b/lib/public_key/doc/guides/public_key_records.md index cfd56258b028..8857edbd0157 100644 --- a/lib/public_key/doc/guides/public_key_records.md +++ b/lib/public_key/doc/guides/public_key_records.md @@ -262,7 +262,7 @@ type The available OID names are as follows: -| _OID Name_ | +| OID Name | | -------------------------------------------- | | id-dsa-with-sha1 | | id-dsaWithSHA1 (ISO or OID to above) | @@ -289,7 +289,7 @@ record: The attribute OID name atoms and their corresponding value types are as follows: -| _OID Name_ | _Value Type_ | +| OID Name | Value Type | | ------------------------- | ----------------------------- | | id-at-name | special_string() | | id-at-surname | special_string() | @@ -331,7 +331,7 @@ records: The public-key algorithm OID name atoms are as follows: -| _OID Name_ | +| OID Name | | ----------------------- | | rsaEncryption | | id-dsa | @@ -362,7 +362,7 @@ _Table: Public-Key Algorithm OIDs_ The standard certificate extensions OID name atoms and their corresponding value types are as follows: -| _OID Name_ | _Value Type_ | +| OID Name | Value Type | | -------------------------------- | ------------------------------ | | id-ce-authorityKeyIdentifier | \#'AuthorityKeyIdentifier'\{\} | | id-ce-subjectKeyIdentifier | oid() | @@ -378,7 +378,7 @@ types are as follows: | id-ce-policyConstraints | \#'PolicyConstraints'\{\} | | id-ce-extKeyUsage | \[id_key_purpose()] | | id-ce-cRLDistributionPoints | \[#'DistributionPoint'\{\}] | -| id-ce-inhibitAnyPolicy | pos_integer() | +| id-ce-inhibitAnyPolicy | pos_integer() | | id-ce-freshestCRL | \[#'DistributionPoint'\{\}] | _Table: Standard Certificate Extensions_ @@ -392,7 +392,7 @@ key_usage() = digitalSignature | nonRepudiation | keyEncipherment ``` And for `id_key_purpose()`: -| _OID Name_ | +| OID Name | | --------------------- | | id-kp-serverAuth | | id-kp-clientAuth | @@ -480,7 +480,7 @@ _Table: Key Purpose OIDs_ The private internet extensions OID name atoms and their corresponding value types are as follows: -| _OID Name_ | _Value Type_ | +| OID Name | Value Type | | ------------------------- | --------------------------- | | id-pe-authorityInfoAccess | \[#'AccessDescription'\{\}] | | id-pe-subjectInfoAccess | \[#'AccessDescription'\{\}] | @@ -530,12 +530,12 @@ specifications and RFC 5280 are as follows: The CRL extensions OID name atoms and their corresponding value types are as follows: -| _OID Name_ | _Value Type_ | +| OID Name | Value Type | | ------------------------------ | ----------------------------------------------- | | id-ce-authorityKeyIdentifier | \#'AuthorityKeyIdentifier\{\} | | id-ce-issuerAltName | \{rdnSequence, \[#AttributeTypeAndValue'\{\}]\} | -| id-ce-cRLNumber | pos_integer() | -| id-ce-deltaCRLIndicator | pos_integer() | +| id-ce-cRLNumber | pos_integer() | +| id-ce-deltaCRLIndicator | pos_integer() | | id-ce-issuingDistributionPoint | \#'IssuingDistributionPoint'\{\} | | id-ce-freshestCRL | \[#'Distributionpoint'\{\}] | @@ -562,7 +562,7 @@ Erlang record: The CRL entry extensions OID name atoms and their corresponding value types are as follows: -| _OID Name_ | _Value Type_ | +| OID Name | Value Type | | ------------------------- | -------------- | | id-ce-cRLReason | crl_reason() | | id-ce-holdInstructionCode | oid() | diff --git a/lib/ssl/doc/guides/standards_compliance.md b/lib/ssl/doc/guides/standards_compliance.md index 92ac873b5ae2..7c38a55684e9 100644 --- a/lib/ssl/doc/guides/standards_compliance.md +++ b/lib/ssl/doc/guides/standards_compliance.md @@ -124,312 +124,312 @@ Applicable) [](){: #soc_table } -| _Section_ | _Feature_ | _State_ | _Since_ | -| --------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ------- | -| [1\.3. Updates Affecting TLS 1.2](https://tools.ietf.org/html/rfc8446#section-1.2) | | _C_ | _24\.1_ | -| | Version downgrade protection mechanism | _C_ | _22_ | -| | RSASSA-PSS signature schemes | _C_ | _24\.1_ | -| | supported_versions (ClientHello) extension | _C_ | _22_ | -| | signature_algorithms_cert extension | _C_ | _24\.1_ | -| [2\. Protocol Overview](https://tools.ietf.org/html/rfc8446#section/2) | | _PC_ | _22_ | -| | (EC)DHE | _C_ | _22_ | -| | PSK-only | _NC_ | | -| | PSK with (EC)DHE | _C_ | _22\.2_ | -| [2\.1. Incorrect DHE share](https://tools.ietf.org/html/rfc8446#section-2.1) | HelloRetryRequest | _C_ | _22_ | -| [2\.2. Resumption and Pre-Shared Key (PSK)](https://tools.ietf.org/html/rfc8446#section-2.2) | | _C_ | _22\.2_ | -| [2\.3. 0-RTT Data](https://tools.ietf.org/html/rfc8446#section-2.3) | | _PC_ | _23\.3_ | -| [4\.1.1. Cryptographic Negotiation](https://tools.ietf.org/html/rfc8446#section-4.1.1) | | _C_ | _22\.2_ | -| | supported_groups extension | _C_ | _22_ | -| | signature_algorithms extension | _C_ | _22_ | -| | pre_shared_key extension | _C_ | _22\.2_ | -| [4\.1.2. Client Hello](https://tools.ietf.org/html/rfc8446#section-4.1.2) | _Client_ | _PC_ | _22\.1_ | -| | server_name (RFC6066) | _C_ | _23\.2_ | -| | max_fragment_length (RFC6066) | _C_ | _23\.0_ | -| | status_request (RFC6066) | _C_ | _27\.0_ | -| | supported_groups (RFC7919) | _C_ | _22\.1_ | -| | signature_algorithms (RFC8446) | _C_ | _22\.1_ | -| | use_srtp (RFC5764) | _C_ | 26\.0 | -| | heartbeat (RFC6520) | _NC_ | | -| | application_layer_protocol_negotiation (RFC7301) | _C_ | _22\.1_ | -| | signed_certificate_timestamp (RFC6962) | _NC_ | | -| | client_certificate_type (RFC7250) | _NC_ | | -| | server_certificate_type (RFC7250) | _NC_ | | -| | padding (RFC7685) | _NC_ | | -| | key_share (RFC8446) | _C_ | _22\.1_ | -| | pre_shared_key (RFC8446) | _C_ | _22\.2_ | -| | psk_key_exchange_modes (RFC8446) | _C_ | _22\.2_ | -| | early_data (RFC8446) | _C_ | _23\.3_ | -| | cookie (RFC8446) | _C_ | _23\.1_ | -| | supported_versions (RFC8446) | _C_ | _22\.1_ | -| | certificate_authorities (RFC8446) | _C_ | 24\.3 | -| | oid_filters (RFC8446) | _NC_ | | -| | post_handshake_auth (RFC8446) | _NC_ | | -| | signature_algorithms_cert (RFC8446) | _C_ | _22\.1_ | -| | _Server_ | _PC_ | _22_ | -| | server_name (RFC6066) | _C_ | _23\.2_ | -| | max_fragment_length (RFC6066) | _C_ | _23\.0_ | -| | status_request (RFC6066) | _NC_ | | -| | supported_groups (RFC7919) | _C_ | _22_ | -| | signature_algorithms (RFC8446) | _C_ | _22_ | -| | use_srtp (RFC5764) | _C_ | 26\.0 | -| | heartbeat (RFC6520) | _NC_ | | -| | application_layer_protocol_negotiation (RFC7301) | _C_ | _22\.1_ | -| | signed_certificate_timestamp (RFC6962) | _NC_ | | -| | client_certificate_type (RFC7250) | _NC_ | | -| | server_certificate_type (RFC7250) | _NC_ | | -| | padding (RFC7685) | _NC_ | | -| | key_share (RFC8446) | _C_ | _22_ | -| | pre_shared_key (RFC8446) | _C_ | _22\.2_ | -| | psk_key_exchange_modes (RFC8446) | _C_ | _22\.2_ | -| | early_data (RFC8446) | _C_ | _23\.3_ | -| | cookie (RFC8446) | _C_ | _23\.1_ | -| | supported_versions (RFC8446) | _C_ | _22_ | -| | oid_filters (RFC8446) | _NC_ | | -| | post_handshake_auth (RFC8446) | _NC_ | | -| | signature_algorithms_cert (RFC8446) | _C_ | _22_ | -| [4\.1.3. Server Hello](https://tools.ietf.org/html/rfc8446#section-4.1.3) | _Client_ | _C_ | _22\.2_ | -| | Version downgrade protection | _C_ | _22\.1_ | -| | key_share (RFC8446) | _C_ | _22\.1_ | -| | pre_shared_key (RFC8446) | _C_ | _22\.2_ | -| | supported_versions (RFC8446) | _C_ | _22\.1_ | -| | use_srtp (RFC5764) | _C_ | 26\.0 | -| | _Server_ | _C_ | _22\.2_ | -| | Version downgrade protection | _C_ | _22_ | -| | key_share (RFC8446) | _C_ | _22_ | -| | pre_shared_key (RFC8446) | _C_ | _22\.2_ | -| | supported_versions (RFC8446) | _C_ | _22_ | -| | use_srtp (RFC5764) | _C_ | 26\.0 | -| [4\.1.4. Hello Retry Request](https://tools.ietf.org/html/rfc8446#section-4.1.4) | _Server_ | _C_ | _22_ | -| | key_share (RFC8446) | _C_ | _22_ | -| | cookie (RFC8446) | _C_ | _23\.1_ | -| | supported_versions (RFC8446) | _C_ | _22_ | -| [4\.2.1. Supported Versions](https://tools.ietf.org/html/rfc8446#section-4.2.1) | _Client_ | _C_ | _22\.1_ | -| | _Server_ | _C_ | _22_ | -| [4\.2.2. Cookie](https://tools.ietf.org/html/rfc8446#section-4.2.2) | _Client_ | _C_ | _23\.1_ | -| | _Server_ | _C_ | _23\.1_ | -| [4\.2.3. Signature Algorithms](https://tools.ietf.org/html/rfc8446#section-4.2.3) | _Client_ | _C_ | _24_ | -| | rsa_pkcs1_sha256 | _C_ | _22\.1_ | -| | rsa_pkcs1_sha384 | _C_ | _22\.1_ | -| | rsa_pkcs1_sha512 | _C_ | _22\.1_ | -| | ecdsa_secp256r1_sha256 | _C_ | _22\.1_ | -| | ecdsa_secp384r1_sha384 | _C_ | _22\.1_ | -| | ecdsa_secp521r1_sha512 | _C_ | _22\.1_ | -| | rsa_pss_rsae_sha256 | _C_ | _22\.1_ | -| | rsa_pss_rsae_sha384 | _C_ | _22\.1_ | -| | rsa_pss_rsae_sha512 | _C_ | _22\.1_ | -| | ed25519 | _C_ | _24_ | -| | ed448 | _C_ | _24_ | -| | rsa_pss_pss_sha256 | _C_ | _23_ | -| | rsa_pss_pss_sha384 | _C_ | _23_ | -| | rsa_pss_pss_sha512 | _C_ | _23_ | -| | rsa_pkcs1_sha1 | _C_ | _22\.1_ | -| | ecdsa_sha1 | _C_ | _22\.1_ | -| | _Server_ | _C_ | _24_ | -| | rsa_pkcs1_sha256 | _C_ | _22_ | -| | rsa_pkcs1_sha384 | _C_ | _22_ | -| | rsa_pkcs1_sha512 | _C_ | _22_ | -| | ecdsa_secp256r1_sha256 | _C_ | _22\.1_ | -| | ecdsa_secp384r1_sha384 | _C_ | _22\.1_ | -| | ecdsa_secp521r1_sha512 | _C_ | _22\.1_ | -| | rsa_pss_rsae_sha256 | _C_ | _22_ | -| | rsa_pss_rsae_sha384 | _C_ | _22_ | -| | rsa_pss_rsae_sha512 | _C_ | _22_ | -| | ed25519 | _C_ | _24_ | -| | ed448 | _C_ | _24_ | -| | rsa_pss_pss_sha256 | _C_ | _23_ | -| | rsa_pss_pss_sha384 | _C_ | _23_ | -| | rsa_pss_pss_sha512 | _C_ | _23_ | -| | rsa_pkcs1_sha1 | _C_ | _22_ | -| | ecdsa_sha1 | _C_ | _22_ | -| [4\.2.4. Certificate Authorities](https://tools.ietf.org/html/rfc8446#section-4.2.4) | _Client_ | _C_ | 24\.3 | -| | _Server_ | _C_ | _24\.3_ | -| [4\.2.5. OID Filters](https://tools.ietf.org/html/rfc8446#section-4.2.5) | _Client_ | _NC_ | | -| | _Server_ | _NC_ | | -| [4\.2.6. Post-Handshake Client Authentication](https://tools.ietf.org/html/rfc8446#section-4.2.6) | _Client_ | _NC_ | | -| | _Server_ | _NC_ | | -| [4\.2.7. Supported Groups](https://tools.ietf.org/html/rfc8446#section-4.2.7) | _Client_ | _C_ | _22\.1_ | -| | secp256r1 | _C_ | _22\.1_ | -| | secp384r1 | _C_ | _22\.1_ | -| | secp521r1 | _C_ | _22\.1_ | -| | x25519 | _C_ | _22\.1_ | -| | x448 | _C_ | _22\.1_ | -| | ffdhe2048 | _C_ | _22\.1_ | -| | ffdhe3072 | _C_ | _22\.1_ | -| | ffdhe4096 | _C_ | _22\.1_ | -| | ffdhe6144 | _C_ | _22\.1_ | -| | ffdhe8192 | _C_ | _22\.1_ | -| | _Server_ | _C_ | _22_ | -| | secp256r1 | _C_ | _22_ | -| | secp384r1 | _C_ | _22_ | -| | secp521r1 | _C_ | _22_ | -| | x25519 | _C_ | _22_ | -| | x448 | _C_ | _22_ | -| | ffdhe2048 | _C_ | _22_ | -| | ffdhe3072 | _C_ | _22_ | -| | ffdhe4096 | _C_ | _22_ | -| | ffdhe6144 | _C_ | _22_ | -| | ffdhe8192 | _C_ | _22_ | -| [4\.2.8. Key Share](https://tools.ietf.org/html/rfc8446#section-4.2.8) | _Client_ | _C_ | _22\.1_ | -| | _Server_ | _C_ | _22_ | -| [4\.2.9. Pre-Shared Key Exchange Modes](https://tools.ietf.org/html/rfc8446#section-4.2.9) | _Client_ | _C_ | _22\.2_ | -| | _Server_ | _C_ | _22\.2_ | -| [4\.2.10. Early Data Indication](https://tools.ietf.org/html/rfc8446#section-4.2.10) | _Client_ | _C_ | _23\.3_ | -| | _Server_ | _C_ | _23\.3_ | -| [4\.2.11. Pre-Shared Key Extension](https://tools.ietf.org/html/rfc8446#section-4.2.11) | _Client_ | _C_ | _22\.2_ | -| | _Server_ | _C_ | _22\.2_ | -| [4\.2.11.1. Ticket Age](https://tools.ietf.org/html/rfc8446#section-4.2.11.1) | _Client_ | _C_ | _22\.2_ | -| | _Server_ | _C_ | _22\.2_ | -| [4\.2.11.2. PSK Binder](https://tools.ietf.org/html/rfc8446#section-4.2.11.2) | _Client_ | _C_ | _22\.2_ | -| | _Server_ | _C_ | _22\.2_ | -| [4\.2.11.3. Processing Order](https://tools.ietf.org/html/rfc8446#section-4.2.11.3) | _Client_ | _NC_ | | -| | _Server_ | _NC_ | | -| [4\.3.1. Encrypted Extensions](https://tools.ietf.org/html/rfc8446#section-4.3.1) | _Client_ | _PC_ | _22\.1_ | -| | server_name (RFC6066) | _C_ | _23\.2_ | -| | max_fragment_length (RFC6066) | _C_ | _23\.0_ | -| | supported_groups (RFC7919) | _NC_ | | -| | use_srtp (RFC5764) | _NC_ | | -| | heartbeat (RFC6520) | _NC_ | | -| | application_layer_protocol_negotiation (RFC7301) | _C_ | 23\.0 | -| | client_certificate_type (RFC7250) | _NC_ | | -| | server_certificate_type (RFC7250) | _NC_ | | -| | early_data (RFC8446) | _C_ | _23\.3_ | -| | _Server_ | _PC_ | _22_ | -| | server_name (RFC6066) | _C_ | _23\.2_ | -| | max_fragment_length (RFC6066) | _C_ | _23\.0_ | -| | supported_groups (RFC7919) | _NC_ | | -| | use_srtp (RFC5764) | _NC_ | | -| | heartbeat (RFC6520) | _NC_ | | -| | application_layer_protocol_negotiation (RFC7301) | _C_ | 23\.0 | -| | client_certificate_type (RFC7250) | _NC_ | | -| | server_certificate_type (RFC7250) | _NC_ | | -| | early_data (RFC8446) | _C_ | _23\.3_ | -| [4\.3.2. Certificate Request](https://tools.ietf.org/html/rfc8446#section-4.3.2) | _Client_ | _PC_ | _22\.1_ | -| | status_request (RFC6066) | _NC_ | | -| | signature_algorithms (RFC8446) | _C_ | _22\.1_ | -| | signed_certificate_timestamp (RFC6962) | _NC_ | | -| | certificate_authorities (RFC8446) | _C_ | 24\.3 | -| | oid_filters (RFC8446) | _NC_ | | -| | signature_algorithms_cert (RFC8446) | _C_ | _22\.1_ | -| | _Server_ | _PC_ | _22_ | -| | status_request (RFC6066) | _NC_ | | -| | signature_algorithms (RFC8446) | _C_ | _22_ | -| | signed_certificate_timestamp (RFC6962) | _NC_ | | -| | certificate_authorities (RFC8446) | _C_ | 24\.3 | -| | oid_filters (RFC8446) | _NC_ | | -| | signature_algorithms_cert (RFC8446) | _C_ | _22_ | -| [4\.4.1. The Transcript Hash](https://tools.ietf.org/html/rfc8446#section-4.4.1) | | _C_ | _22_ | -| [4\.4.2. Certificate](https://tools.ietf.org/html/rfc8446#section-4.4.2) | _Client_ | _PC_ | _22\.1_ | -| | Arbitrary certificate chain orderings | _C_ | _22\.2_ | -| | Extraneous certificates in chain | _C_ | _23\.2_ | -| | status_request (RFC6066) | _C_ | 27\.0 | -| | signed_certificate_timestamp (RFC6962) | _NC_ | | -| | _Server_ | _PC_ | _22_ | -| | status_request (RFC6066) | _NC_ | | -| | signed_certificate_timestamp (RFC6962) | _NC_ | | -| [4\.4.2.1. OCSP Status and SCT Extensions](https://tools.ietf.org/html/rfc8446#section-4.4.2.1) | _Client_ | _PC_ | _27\.0_ | -| | _Server_ | _NC_ | | -| [4\.4.2.2. Server Certificate Selection](https://tools.ietf.org/html/rfc8446#section-4.4.2.2) | | _C_ | _24\.3_ | -| | The certificate type MUST be X.509v3, unless explicitly negotiated otherwise | _C_ | _22_ | -| | The server's end-entity certificate's public key (and associated restrictions) MUST be compatible with the selected authentication algorithm from the client's "signature_algorithms" extension (currently RSA, ECDSA, or EdDSA). | _C_ | _22_ | -| | The certificate MUST allow the key to be used for signing with a signature scheme indicated in the client's "signature_algorithms"/"signature_algorithms_cert" extensions | _C_ | _22_ | -| | The "server_name" and "certificate_authorities" extensions are used to guide certificate selection. As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension, when applicable. | _C_ | _24\.3_ | -| [4\.4.2.3. Client Certificate Selection](https://tools.ietf.org/html/rfc8446#section-4.4.2.3) | | _PC_ | _22\.1_ | -| | The certificate type MUST be X.509v3, unless explicitly negotiated otherwise | _C_ | _22\.1_ | -| | If the "certificate_authorities" extension in the CertificateRequest message was present, at least one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs. | _C_ | _24\.3_ | -| | The certificates MUST be signed using an acceptable signature algorithm | _C_ | _22\.1_ | -| | If the CertificateRequest message contained a non-empty "oid_filters" extension, the end-entity certificate MUST match the extension OIDs that are recognized by the client | _NC_ | | -| [4\.4.2.4. Receiving a Certificate Message](https://tools.ietf.org/html/rfc8446#section-4.4.2.4) | _Client_ | _C_ | _22\.1_ | -| | _Server_ | _C_ | _22_ | -| [4\.4.3. Certificate Verify](https://tools.ietf.org/html/rfc8446#section-4.4.3) | _Client_ | _C_ | _22\.1_ | -| | _Server_ | _C_ | _22_ | -| [4\.4.4. Finished](https://tools.ietf.org/html/rfc8446#section-4.4.4) | _Client_ | _C_ | _22\.1_ | -| | _Server_ | _C_ | _22_ | -| [4\.5. End of Early Data](https://tools.ietf.org/html/rfc8446#section-4.5) | _Client_ | _C_ | _23\.3_ | -| | _Server_ | _C_ | _23\.3_ | -| [4\.6.1. New Session Ticket Message](https://tools.ietf.org/html/rfc8446#section-4.6.1) | _Client_ | _C_ | _23\.3_ | -| | early_data (RFC8446) | _C_ | _23\.3_ | -| | _Server_ | _C_ | _23\.3_ | -| | early_data (RFC8446) | _C_ | _23\.3_ | -| [4\.6.2. Post-Handshake Authentication](https://tools.ietf.org/html/rfc8446#section-4.6.2) | _Client_ | _NC_ | | -| | _Server_ | _NC_ | | -| [4\.6.3. Key and Initialization Vector Update](https://tools.ietf.org/html/rfc8446#section-4.6.3) | _Client_ | _C_ | _22\.3_ | -| | _Server_ | _C_ | _22\.3_ | -| [5\.1. Record Layer](https://tools.ietf.org/html/rfc8446#section-5.1) | | _C_ | _22_ | -| | MUST NOT be interleaved with other record types | _C_ | _22_ | -| | MUST NOT span key changes | _C_ | _22_ | -| | MUST NOT send zero-length fragments | _C_ | _22_ | -| | Alert messages MUST NOT be fragmented | _C_ | _22_ | -| [5\.2. Record Payload Protection](https://tools.ietf.org/html/rfc8446#section-5.2) | | _C_ | _22_ | -| [5\.3. Per-Record Nonce](https://tools.ietf.org/html/rfc8446#section-5.3) | | _C_ | _22_ | -| [5\.4. Record Padding](https://tools.ietf.org/html/rfc8446#section-5.4) | | _PC_ | _22_ | -| | MAY choose to pad | _NC_ | | -| | MUST NOT send Handshake and Alert records that have a zero-length TLSInnerPlaintext.content | _NC_ | | -| | The padding sent is automatically verified | _C_ | _22_ | -| [5\.5. Limits on Key Usage](https://tools.ietf.org/html/rfc8446#section-5.5) | | _C_ | _22\.3_ | -| [6\.1. Closure Alerts](https://tools.ietf.org/html/rfc8446#section-6.1) | | _22_ | | -| | close_notify | _C_ | _22_ | | -| | user_cancelled | _C_ | _22_ | | -| [6\.2. Error Alerts](https://tools.ietf.org/html/rfc8446#section-6.2) | | _PC_ | _22_ | -| [7\.1. Key Schedule](https://tools.ietf.org/html/rfc8446#section-7.1) | | _C_ | _22_ | -| [7\.2. Updating Traffic Secrets](https://tools.ietf.org/html/rfc8446#section-7.2) | | _C_ | _22_ | -| [7\.3. Traffic Key Calculation](https://tools.ietf.org/html/rfc8446#section-7.3) | | _C_ | _22_ | -| [7\.5. Exporters](https://tools.ietf.org/html/rfc8446#section-7.5) | | _PC_ | _26\.3_ | -| [8\. 0-RTT and Anti-Replay](https://tools.ietf.org/html/rfc8446#section/8) | | _C_ | _22\.2_ | -| [8\.1. Single-Use Tickets](https://tools.ietf.org/html/rfc8446#section-8.1) | | _C_ | _22\.2_ | -| [8\.2. Client Hello Recording](https://tools.ietf.org/html/rfc8446#section-8.2) | | _C_ | _22\.2_ | -| [8\.3. Freshness Checks](https://tools.ietf.org/html/rfc8446#section-8.3) | | _C_ | _22\.2_ | -| [9\.1. Mandatory-to-Implement Cipher Suites](https://tools.ietf.org/html/rfc8446#section-9.1) | | _C_ | _22\.1_ | -| | MUST implement the TLS_AES_128_GCM_SHA256 | _C_ | _22_ | -| | SHOULD implement the TLS_AES_256_GCM_SHA384 | _C_ | _22_ | -| | SHOULD implement the TLS_CHACHA20_POLY1305_SHA256 | _C_ | _22_ | -| | _Digital signatures_ | _C_ | _22\.1_ | -| | MUST support rsa_pkcs1_sha256 (for certificates) | _C_ | _22_ | -| | MUST support rsa_pss_rsae_sha256 (for CertificateVerify and certificates) | _C_ | _22_ | -| | MUST support ecdsa_secp256r1_sha256 | _C_ | _22\.1_ | -| | _Key Exchange_ | _C_ | _22_ | -| | MUST support key exchange with secp256r1 | _C_ | _22_ | -| | SHOULD support key exchange with X25519 | _C_ | _22_ | -| [9\.2. Mandatory-to-Implement Extensions](https://tools.ietf.org/html/rfc8446#section-9.2) | | _C_ | _23\.2_ | -| | Supported Versions | _C_ | _22_ | -| | Cookie | _C_ | _23\.1_ | -| | Signature Algorithms | _C_ | _22_ | -| | Signature Algorithms Certificate | _C_ | _22_ | -| | Negotiated Groups | _C_ | _22_ | -| | Key Share | _C_ | _22_ | -| | Server Name Indication | _C_ | _23\.2_ | -| | _MUST send and use these extensions_ | _C_ | _22\.2_ | -| | "supported_versions" is REQUIRED for ClientHello, ServerHello and HelloRetryRequest | _C_ | _22\.1_ | -| | "signature_algorithms" is REQUIRED for certificate authentication | _C_ | _22_ | -| | "supported_groups" is REQUIRED for ClientHello messages using (EC)DHE key exchange | _C_ | _22_ | -| | "key_share" is REQUIRED for (EC)DHE key exchange | _C_ | _22_ | -| | "pre_shared_key" is REQUIRED for PSK key agreement | _C_ | _22\.2_ | -| | "psk_key_exchange_modes" is REQUIRED for PSK key agreement | _C_ | _22\.2_ | -| | _TLS 1.3 ClientHello_ | _C_ | _22\.1_ | -| | If not containing a "pre_shared_key" extension, it MUST contain both a "signature_algorithms" extension and a "supported_groups" extension. | _C_ | _22\.1_ | -| | If containing a "supported_groups" extension, it MUST also contain a "key_share" extension, and vice versa. An empty KeyShare.client_shares vector is permitted. | _C_ | _22\.1_ | -| | _TLS 1.3 ServerHello_ | _C_ | _23\.2_ | -| | MUST support the use of the "server_name" extension | _C_ | _23\.2_ | -| [9\.3. Protocol Invariants](https://tools.ietf.org/html/rfc8446#section-9.3) | | _C_ | _22\.1_ | -| | _MUST correctly handle extensible fields_ | _C_ | _22\.1_ | -| | A client sending a ClientHello MUST support all parameters advertised in it. Otherwise, the server may fail to interoperate by selecting one of those parameters. | _C_ | _22\.1_ | -| | A server receiving a ClientHello MUST correctly ignore all unrecognized cipher suites, extensions, and other parameters. Otherwise, it may fail to interoperate with newer clients. In TLS 1.3, a client receiving a CertificateRequest or NewSessionTicket MUST also ignore all unrecognized extensions. | _C_ | _22\.1_ | -| | A middlebox which terminates a TLS connection MUST behave as a compliant TLS server | _NA_ | | -| | A middlebox which forwards ClientHello parameters it does not understand MUST NOT process any messages beyond that ClientHello. It MUST forward all subsequent traffic unmodified. Otherwise, it may fail to interoperate with newer clients and servers. | _NA_ | | -| [B.4. Cipher Suites](https://tools.ietf.org/html/rfc8446#section-B.4) | | _C_ | _23_ | -| | TLS_AES_128_GCM_SHA256 | _C_ | _22_ | -| | TLS_AES_256_GCM_SHA384 | _C_ | _22_ | -| | TLS_CHACHA20_POLY1305_SHA256 | _C_ | _22_ | -| | TLS_AES_128_CCM_SHA256 | _C_ | _22_ | -| | TLS_AES_128_CCM_8_SHA256 | _C_ | _23_ | -| [C.1. Random Number Generation and Seeding](https://tools.ietf.org/html/rfc8446#section-C.1) | | _C_ | _22_ | -| [C.2. Certificates and Authentication](https://tools.ietf.org/html/rfc8446#section-C.2) | | _C_ | _22_ | -| [C.3. Implementation Pitfalls](https://tools.ietf.org/html/rfc8446#section-C.3) | | _PC_ | _22_ | -| [C.4. Client Tracking Prevention](https://tools.ietf.org/html/rfc8446#section-C.4) | | _C_ | _22\.2_ | -| [C.5. Unauthenticated Operation](https://tools.ietf.org/html/rfc8446#section-C.5) | | _C_ | _22_ | -| [D.1. Negotiating with an Older Server](https://tools.ietf.org/html/rfc8446#section-D.1) | | _C_ | _22\.2_ | -| [D.2. Negotiating with an Older Client](https://tools.ietf.org/html/rfc8446#section-D.2) | | _C_ | _22_ | -| [D.3. 0-RTT Backward Compatibility](https://tools.ietf.org/html/rfc8446#section-D.3) | | _NC_ | | -| [D.4. Middlebox Compatibility Mode](https://tools.ietf.org/html/rfc8446#section-D.4) | | _C_ | _23_ | -| [D.5. Security Restrictions Related to Backward Compatibility](https://tools.ietf.org/html/rfc8446#section-D.5) | | _C_ | _22_ | +| Section | Feature | State | Since | +| --------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- | ----- | +| [1\.3. Updates Affecting TLS 1.2](https://tools.ietf.org/html/rfc8446#section-1.2) | | C | 24\.1 | +| | Version downgrade protection mechanism | C | 22 | +| | RSASSA-PSS signature schemes | C | 24\.1 | +| | supported_versions (ClientHello) extension | C | 22 | +| | signature_algorithms_cert extension | C | 24\.1 | +| [2\. Protocol Overview](https://tools.ietf.org/html/rfc8446#section/2) | | PC | 22 | +| | (EC)DHE | C | 22 | +| | PSK-only | NC | | +| | PSK with (EC)DHE | C | 22\.2 | +| [2\.1. Incorrect DHE share](https://tools.ietf.org/html/rfc8446#section-2.1) | HelloRetryRequest | C | 22 | +| [2\.2. Resumption and Pre-Shared Key (PSK)](https://tools.ietf.org/html/rfc8446#section-2.2) | | C | 22\.2 | +| [2\.3. 0-RTT Data](https://tools.ietf.org/html/rfc8446#section-2.3) | | PC | 23\.3 | +| [4\.1.1. Cryptographic Negotiation](https://tools.ietf.org/html/rfc8446#section-4.1.1) | | C | 22\.2 | +| | supported_groups extension | C | 22 | +| | signature_algorithms extension | C | 22 | +| | pre_shared_key extension | C | 22\.2 | +| [4\.1.2. Client Hello](https://tools.ietf.org/html/rfc8446#section-4.1.2) | Client | PC | 22\.1 | +| | server_name (RFC6066) | C | 23\.2 | +| | max_fragment_length (RFC6066) | C | 23\.0 | +| | status_request (RFC6066) | C | 27\.0 | +| | supported_groups (RFC7919) | C | 22\.1 | +| | signature_algorithms (RFC8446) | C | 22\.1 | +| | use_srtp (RFC5764) | C | 26\.0 | +| | heartbeat (RFC6520) | NC | | +| | application_layer_protocol_negotiation (RFC7301) | C | 22\.1 | +| | signed_certificate_timestamp (RFC6962) | NC | | +| | client_certificate_type (RFC7250) | NC | | +| | server_certificate_type (RFC7250) | NC | | +| | padding (RFC7685) | NC | | +| | key_share (RFC8446) | C | 22\.1 | +| | pre_shared_key (RFC8446) | C | 22\.2 | +| | psk_key_exchange_modes (RFC8446) | C | 22\.2 | +| | early_data (RFC8446) | C | 23\.3 | +| | cookie (RFC8446) | C | 23\.1 | +| | supported_versions (RFC8446) | C | 22\.1 | +| | certificate_authorities (RFC8446) | C | 24\.3 | +| | oid_filters (RFC8446) | NC | | +| | post_handshake_auth (RFC8446) | NC | | +| | signature_algorithms_cert (RFC8446) | C | 22\.1 | +| | Server | PC | 22 | +| | server_name (RFC6066) | C | 23\.2 | +| | max_fragment_length (RFC6066) | C | 23\.0 | +| | status_request (RFC6066) | NC | | +| | supported_groups (RFC7919) | C | 22 | +| | signature_algorithms (RFC8446) | C | 22 | +| | use_srtp (RFC5764) | C | 26\.0 | +| | heartbeat (RFC6520) | NC | | +| | application_layer_protocol_negotiation (RFC7301) | C | 22\.1 | +| | signed_certificate_timestamp (RFC6962) | NC | | +| | client_certificate_type (RFC7250) | NC | | +| | server_certificate_type (RFC7250) | NC | | +| | padding (RFC7685) | NC | | +| | key_share (RFC8446) | C | 22 | +| | pre_shared_key (RFC8446) | C | 22\.2 | +| | psk_key_exchange_modes (RFC8446) | C | 22\.2 | +| | early_data (RFC8446) | C | 23\.3 | +| | cookie (RFC8446) | C | 23\.1 | +| | supported_versions (RFC8446) | C | 22 | +| | oid_filters (RFC8446) | NC | | +| | post_handshake_auth (RFC8446) | NC | | +| | signature_algorithms_cert (RFC8446) | C | 22 | +| [4\.1.3. Server Hello](https://tools.ietf.org/html/rfc8446#section-4.1.3) | Client | C | 22\.2 | +| | Version downgrade protection | C | 22\.1 | +| | key_share (RFC8446) | C | 22\.1 | +| | pre_shared_key (RFC8446) | C | 22\.2 | +| | supported_versions (RFC8446) | C | 22\.1 | +| | use_srtp (RFC5764) | C | 26\.0 | +| | Server | C | 22\.2 | +| | Version downgrade protection | C | 22 | +| | key_share (RFC8446) | C | 22 | +| | pre_shared_key (RFC8446) | C | 22\.2 | +| | supported_versions (RFC8446) | C | 22 | +| | use_srtp (RFC5764) | C | 26\.0 | +| [4\.1.4. Hello Retry Request](https://tools.ietf.org/html/rfc8446#section-4.1.4) | Server | C | 22 | +| | key_share (RFC8446) | C | 22 | +| | cookie (RFC8446) | C | 23\.1 | +| | supported_versions (RFC8446) | C | 22 | +| [4\.2.1. Supported Versions](https://tools.ietf.org/html/rfc8446#section-4.2.1) | Client | C | 22\.1 | +| | Server | C | 22 | +| [4\.2.2. Cookie](https://tools.ietf.org/html/rfc8446#section-4.2.2) | Client | C | 23\.1 | +| | Server | C | 23\.1 | +| [4\.2.3. Signature Algorithms](https://tools.ietf.org/html/rfc8446#section-4.2.3) | Client | C | 24 | +| | rsa_pkcs1_sha256 | C | 22\.1 | +| | rsa_pkcs1_sha384 | C | 22\.1 | +| | rsa_pkcs1_sha512 | C | 22\.1 | +| | ecdsa_secp256r1_sha256 | C | 22\.1 | +| | ecdsa_secp384r1_sha384 | C | 22\.1 | +| | ecdsa_secp521r1_sha512 | C | 22\.1 | +| | rsa_pss_rsae_sha256 | C | 22\.1 | +| | rsa_pss_rsae_sha384 | C | 22\.1 | +| | rsa_pss_rsae_sha512 | C | 22\.1 | +| | ed25519 | C | 24 | +| | ed448 | C | 24 | +| | rsa_pss_pss_sha256 | C | 23 | +| | rsa_pss_pss_sha384 | C | 23 | +| | rsa_pss_pss_sha512 | C | 23 | +| | rsa_pkcs1_sha1 | C | 22\.1 | +| | ecdsa_sha1 | C | 22\.1 | +| | Server | C | 24 | +| | rsa_pkcs1_sha256 | C | 22 | +| | rsa_pkcs1_sha384 | C | 22 | +| | rsa_pkcs1_sha512 | C | 22 | +| | ecdsa_secp256r1_sha256 | C | 22\.1 | +| | ecdsa_secp384r1_sha384 | C | 22\.1 | +| | ecdsa_secp521r1_sha512 | C | 22\.1 | +| | rsa_pss_rsae_sha256 | C | 22 | +| | rsa_pss_rsae_sha384 | C | 22 | +| | rsa_pss_rsae_sha512 | C | 22 | +| | ed25519 | C | 24 | +| | ed448 | C | 24 | +| | rsa_pss_pss_sha256 | C | 23 | +| | rsa_pss_pss_sha384 | C | 23 | +| | rsa_pss_pss_sha512 | C | 23 | +| | rsa_pkcs1_sha1 | C | 22 | +| | ecdsa_sha1 | C | 22 | +| [4\.2.4. Certificate Authorities](https://tools.ietf.org/html/rfc8446#section-4.2.4) | Client | C | 24\.3 | +| | Server | C | 24\.3 | +| [4\.2.5. OID Filters](https://tools.ietf.org/html/rfc8446#section-4.2.5) | Client | NC | | +| | Server | NC | | +| [4\.2.6. Post-Handshake Client Authentication](https://tools.ietf.org/html/rfc8446#section-4.2.6) | Client | NC | | +| | Server | NC | | +| [4\.2.7. Supported Groups](https://tools.ietf.org/html/rfc8446#section-4.2.7) | Client | C | 22\.1 | +| | secp256r1 | C | 22\.1 | +| | secp384r1 | C | 22\.1 | +| | secp521r1 | C | 22\.1 | +| | x25519 | C | 22\.1 | +| | x448 | C | 22\.1 | +| | ffdhe2048 | C | 22\.1 | +| | ffdhe3072 | C | 22\.1 | +| | ffdhe4096 | C | 22\.1 | +| | ffdhe6144 | C | 22\.1 | +| | ffdhe8192 | C | 22\.1 | +| | Server | C | 22 | +| | secp256r1 | C | 22 | +| | secp384r1 | C | 22 | +| | secp521r1 | C | 22 | +| | x25519 | C | 22 | +| | x448 | C | 22 | +| | ffdhe2048 | C | 22 | +| | ffdhe3072 | C | 22 | +| | ffdhe4096 | C | 22 | +| | ffdhe6144 | C | 22 | +| | ffdhe8192 | C | 22 | +| [4\.2.8. Key Share](https://tools.ietf.org/html/rfc8446#section-4.2.8) | Client | C | 22\.1 | +| | Server | C | 22 | +| [4\.2.9. Pre-Shared Key Exchange Modes](https://tools.ietf.org/html/rfc8446#section-4.2.9) | Client | C | 22\.2 | +| | Server | C | 22\.2 | +| [4\.2.10. Early Data Indication](https://tools.ietf.org/html/rfc8446#section-4.2.10) | Client | C | 23\.3 | +| | Server | C | 23\.3 | +| [4\.2.11. Pre-Shared Key Extension](https://tools.ietf.org/html/rfc8446#section-4.2.11) | Client | C | 22\.2 | +| | Server | C | 22\.2 | +| [4\.2.11.1. Ticket Age](https://tools.ietf.org/html/rfc8446#section-4.2.11.1) | Client | C | 22\.2 | +| | Server | C | 22\.2 | +| [4\.2.11.2. PSK Binder](https://tools.ietf.org/html/rfc8446#section-4.2.11.2) | Client | C | 22\.2 | +| | Server | C | 22\.2 | +| [4\.2.11.3. Processing Order](https://tools.ietf.org/html/rfc8446#section-4.2.11.3) | Client | NC | | +| | Server | NC | | +| [4\.3.1. Encrypted Extensions](https://tools.ietf.org/html/rfc8446#section-4.3.1) | Client | PC | 22\.1 | +| | server_name (RFC6066) | C | 23\.2 | +| | max_fragment_length (RFC6066) | C | 23\.0 | +| | supported_groups (RFC7919) | NC | | +| | use_srtp (RFC5764) | NC | | +| | heartbeat (RFC6520) | NC | | +| | application_layer_protocol_negotiation (RFC7301) | C | 23\.0 | +| | client_certificate_type (RFC7250) | NC | | +| | server_certificate_type (RFC7250) | NC | | +| | early_data (RFC8446) | C | 23\.3 | +| | Server | PC | 22 | +| | server_name (RFC6066) | C | 23\.2 | +| | max_fragment_length (RFC6066) | C | 23\.0 | +| | supported_groups (RFC7919) | NC | | +| | use_srtp (RFC5764) | NC | | +| | heartbeat (RFC6520) | NC | | +| | application_layer_protocol_negotiation (RFC7301) | C | 23\.0 | +| | client_certificate_type (RFC7250) | NC | | +| | server_certificate_type (RFC7250) | NC | | +| | early_data (RFC8446) | C | 23\.3 | +| [4\.3.2. Certificate Request](https://tools.ietf.org/html/rfc8446#section-4.3.2) | Client | PC | 22\.1 | +| | status_request (RFC6066) | NC | | +| | signature_algorithms (RFC8446) | C | 22\.1 | +| | signed_certificate_timestamp (RFC6962) | NC | | +| | certificate_authorities (RFC8446) | C | 24\.3 | +| | oid_filters (RFC8446) | NC | | +| | signature_algorithms_cert (RFC8446) | C | 22\.1 | +| | Server | PC | 22 | +| | status_request (RFC6066) | NC | | +| | signature_algorithms (RFC8446) | C | 22 | +| | signed_certificate_timestamp (RFC6962) | NC | | +| | certificate_authorities (RFC8446) | C | 24\.3 | +| | oid_filters (RFC8446) | NC | | +| | signature_algorithms_cert (RFC8446) | C | 22 | +| [4\.4.1. The Transcript Hash](https://tools.ietf.org/html/rfc8446#section-4.4.1) | | C | 22 | +| [4\.4.2. Certificate](https://tools.ietf.org/html/rfc8446#section-4.4.2) | Client | PC | 22\.1 | +| | Arbitrary certificate chain orderings | C | 22\.2 | +| | Extraneous certificates in chain | C | 23\.2 | +| | status_request (RFC6066) | C | 27\.0 | +| | signed_certificate_timestamp (RFC6962) | NC | | +| | Server | PC | 22 | +| | status_request (RFC6066) | NC | | +| | signed_certificate_timestamp (RFC6962) | NC | | +| [4\.4.2.1. OCSP Status and SCT Extensions](https://tools.ietf.org/html/rfc8446#section-4.4.2.1) | Client | PC | 27\.0 | +| | Server | NC | | +| [4\.4.2.2. Server Certificate Selection](https://tools.ietf.org/html/rfc8446#section-4.4.2.2) | | C | 24\.3 | +| | The certificate type MUST be X.509v3, unless explicitly negotiated otherwise | C | 22 | +| | The server's end-entity certificate's public key (and associated restrictions) MUST be compatible with the selected authentication algorithm from the client's "signature_algorithms" extension (currently RSA, ECDSA, or EdDSA). | C | 22 | +| | The certificate MUST allow the key to be used for signing with a signature scheme indicated in the client's "signature_algorithms"/"signature_algorithms_cert" extensions | C | 22 | +| | The "server_name" and "certificate_authorities" extensions are used to guide certificate selection. As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension, when applicable. | C | 24\.3 | +| [4\.4.2.3. Client Certificate Selection](https://tools.ietf.org/html/rfc8446#section-4.4.2.3) | | PC | 22\.1 | +| | The certificate type MUST be X.509v3, unless explicitly negotiated otherwise | C | 22\.1 | +| | If the "certificate_authorities" extension in the CertificateRequest message was present, at least one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs. | C | 24\.3 | +| | The certificates MUST be signed using an acceptable signature algorithm | C | 22\.1 | +| | If the CertificateRequest message contained a non-empty "oid_filters" extension, the end-entity certificate MUST match the extension OIDs that are recognized by the client | NC | | +| [4\.4.2.4. Receiving a Certificate Message](https://tools.ietf.org/html/rfc8446#section-4.4.2.4) | Client | C | 22\.1 | +| | Server | C | 22 | +| [4\.4.3. Certificate Verify](https://tools.ietf.org/html/rfc8446#section-4.4.3) | Client | C | 22\.1 | +| | Server | C | 22 | +| [4\.4.4. Finished](https://tools.ietf.org/html/rfc8446#section-4.4.4) | Client | C | 22\.1 | +| | Server | C | 22 | +| [4\.5. End of Early Data](https://tools.ietf.org/html/rfc8446#section-4.5) | Client | C | 23\.3 | +| | Server | C | 23\.3 | +| [4\.6.1. New Session Ticket Message](https://tools.ietf.org/html/rfc8446#section-4.6.1) | Client | C | 23\.3 | +| | early_data (RFC8446) | C | 23\.3 | +| | Server | C | 23\.3 | +| | early_data (RFC8446) | C | 23\.3 | +| [4\.6.2. Post-Handshake Authentication](https://tools.ietf.org/html/rfc8446#section-4.6.2) | Client | NC | | +| | Server | NC | | +| [4\.6.3. Key and Initialization Vector Update](https://tools.ietf.org/html/rfc8446#section-4.6.3) | Client | C | 22\.3 | +| | Server | C | 22\.3 | +| [5\.1. Record Layer](https://tools.ietf.org/html/rfc8446#section-5.1) | | C | 22 | +| | MUST NOT be interleaved with other record types | C | 22 | +| | MUST NOT span key changes | C | 22 | +| | MUST NOT send zero-length fragments | C | 22 | +| | Alert messages MUST NOT be fragmented | C | 22 | +| [5\.2. Record Payload Protection](https://tools.ietf.org/html/rfc8446#section-5.2) | | C | 22 | +| [5\.3. Per-Record Nonce](https://tools.ietf.org/html/rfc8446#section-5.3) | | C | 22 | +| [5\.4. Record Padding](https://tools.ietf.org/html/rfc8446#section-5.4) | | PC | 22 | +| | MAY choose to pad | NC | | +| | MUST NOT send Handshake and Alert records that have a zero-length TLSInnerPlaintext.content | NC | | +| | The padding sent is automatically verified | C | 22 | +| [5\.5. Limits on Key Usage](https://tools.ietf.org/html/rfc8446#section-5.5) | | C | 22\.3 | +| [6\.1. Closure Alerts](https://tools.ietf.org/html/rfc8446#section-6.1) | | 22 | | +| | close_notify | C | 22 | | +| | user_cancelled | C | 22 | | +| [6\.2. Error Alerts](https://tools.ietf.org/html/rfc8446#section-6.2) | | PC | 22 | +| [7\.1. Key Schedule](https://tools.ietf.org/html/rfc8446#section-7.1) | | C | 22 | +| [7\.2. Updating Traffic Secrets](https://tools.ietf.org/html/rfc8446#section-7.2) | | C | 22 | +| [7\.3. Traffic Key Calculation](https://tools.ietf.org/html/rfc8446#section-7.3) | | C | 22 | +| [7\.5. Exporters](https://tools.ietf.org/html/rfc8446#section-7.5) | | PC | 26\.3 | +| [8\. 0-RTT and Anti-Replay](https://tools.ietf.org/html/rfc8446#section/8) | | C | 22\.2 | +| [8\.1. Single-Use Tickets](https://tools.ietf.org/html/rfc8446#section-8.1) | | C | 22\.2 | +| [8\.2. Client Hello Recording](https://tools.ietf.org/html/rfc8446#section-8.2) | | C | 22\.2 | +| [8\.3. Freshness Checks](https://tools.ietf.org/html/rfc8446#section-8.3) | | C | 22\.2 | +| [9\.1. Mandatory-to-Implement Cipher Suites](https://tools.ietf.org/html/rfc8446#section-9.1) | | C | 22\.1 | +| | MUST implement the TLS_AES_128_GCM_SHA256 | C | 22 | +| | SHOULD implement the TLS_AES_256_GCM_SHA384 | C | 22 | +| | SHOULD implement the TLS_CHACHA20_POLY1305_SHA256 | C | 22 | +| | Digital signatures | C | 22\.1 | +| | MUST support rsa_pkcs1_sha256 (for certificates) | C | 22 | +| | MUST support rsa_pss_rsae_sha256 (for CertificateVerify and certificates) | C | 22 | +| | MUST support ecdsa_secp256r1_sha256 | C | 22\.1 | +| | Key Exchange | C | 22 | +| | MUST support key exchange with secp256r1 | C | 22 | +| | SHOULD support key exchange with X25519 | C | 22 | +| [9\.2. Mandatory-to-Implement Extensions](https://tools.ietf.org/html/rfc8446#section-9.2) | | C | 23\.2 | +| | Supported Versions | C | 22 | +| | Cookie | C | 23\.1 | +| | Signature Algorithms | C | 22 | +| | Signature Algorithms Certificate | C | 22 | +| | Negotiated Groups | C | 22 | +| | Key Share | C | 22 | +| | Server Name Indication | C | 23\.2 | +| | MUST send and use these extensions | C | 22\.2 | +| | "supported_versions" is REQUIRED for ClientHello, ServerHello and HelloRetryRequest | C | 22\.1 | +| | "signature_algorithms" is REQUIRED for certificate authentication | C | 22 | +| | "supported_groups" is REQUIRED for ClientHello messages using (EC)DHE key exchange | C | 22 | +| | "key_share" is REQUIRED for (EC)DHE key exchange | C | 22 | +| | "pre_shared_key" is REQUIRED for PSK key agreement | C | 22\.2 | +| | "psk_key_exchange_modes" is REQUIRED for PSK key agreement | C | 22\.2 | +| | TLS 1.3 ClientHello | C | 22\.1 | +| | If not containing a "pre_shared_key" extension, it MUST contain both a "signature_algorithms" extension and a "supported_groups" extension. | C | 22\.1 | +| | If containing a "supported_groups" extension, it MUST also contain a "key_share" extension, and vice versa. An empty KeyShare.client_shares vector is permitted. | C | 22\.1 | +| | TLS 1.3 ServerHello | C | 23\.2 | +| | MUST support the use of the "server_name" extension | C | 23\.2 | +| [9\.3. Protocol Invariants](https://tools.ietf.org/html/rfc8446#section-9.3) | | C | 22\.1 | +| | MUST correctly handle extensible fields | C | 22\.1 | +| | A client sending a ClientHello MUST support all parameters advertised in it. Otherwise, the server may fail to interoperate by selecting one of those parameters. | C | 22\.1 | +| | A server receiving a ClientHello MUST correctly ignore all unrecognized cipher suites, extensions, and other parameters. Otherwise, it may fail to interoperate with newer clients. In TLS 1.3, a client receiving a CertificateRequest or NewSessionTicket MUST also ignore all unrecognized extensions. | C | 22\.1 | +| | A middlebox which terminates a TLS connection MUST behave as a compliant TLS server | NA | | +| | A middlebox which forwards ClientHello parameters it does not understand MUST NOT process any messages beyond that ClientHello. It MUST forward all subsequent traffic unmodified. Otherwise, it may fail to interoperate with newer clients and servers. | NA | | +| [B.4. Cipher Suites](https://tools.ietf.org/html/rfc8446#section-B.4) | | C | 23 | +| | TLS_AES_128_GCM_SHA256 | C | 22 | +| | TLS_AES_256_GCM_SHA384 | C | 22 | +| | TLS_CHACHA20_POLY1305_SHA256 | C | 22 | +| | TLS_AES_128_CCM_SHA256 | C | 22 | +| | TLS_AES_128_CCM_8_SHA256 | C | 23 | +| [C.1. Random Number Generation and Seeding](https://tools.ietf.org/html/rfc8446#section-C.1) | | C | 22 | +| [C.2. Certificates and Authentication](https://tools.ietf.org/html/rfc8446#section-C.2) | | C | 22 | +| [C.3. Implementation Pitfalls](https://tools.ietf.org/html/rfc8446#section-C.3) | | PC | 22 | +| [C.4. Client Tracking Prevention](https://tools.ietf.org/html/rfc8446#section-C.4) | | C | 22\.2 | +| [C.5. Unauthenticated Operation](https://tools.ietf.org/html/rfc8446#section-C.5) | | C | 22 | +| [D.1. Negotiating with an Older Server](https://tools.ietf.org/html/rfc8446#section-D.1) | | C | 22\.2 | +| [D.2. Negotiating with an Older Client](https://tools.ietf.org/html/rfc8446#section-D.2) | | C | 22 | +| [D.3. 0-RTT Backward Compatibility](https://tools.ietf.org/html/rfc8446#section-D.3) | | NC | | +| [D.4. Middlebox Compatibility Mode](https://tools.ietf.org/html/rfc8446#section-D.4) | | C | 23 | +| [D.5. Security Restrictions Related to Backward Compatibility](https://tools.ietf.org/html/rfc8446#section-D.5) | | C | 22 | _Table: Standards Compliance_ diff --git a/system/doc/efficiency_guide/maps.md b/system/doc/efficiency_guide/maps.md index 961300997023..12637b1138ec 100644 --- a/system/doc/efficiency_guide/maps.md +++ b/system/doc/efficiency_guide/maps.md @@ -142,9 +142,9 @@ elements, or when it shrinks to 32 elements or less. A small map looks like this inside the runtime system: -| 0 | 1 | 2 | 3 | | N | -| :---------: | --- | :----: | :------: | :-----: | :------: | -| **FLATMAP** | _N_ | _Keys_ | _Value1_ | _..._ | _ValueN_ | +| 0 | 1 | 2 | 3 | | N | +| :---------: | --- | :---: | :----: | :---: | :----: | +| **FLATMAP** | N | Keys | Value1 | ... | ValueN | _Table: The representation of a small map_ @@ -163,26 +163,26 @@ _Table: The representation of a small map_ As an example, let us look at how the map `#{a => foo, z => bar}` is represented: -| 0 | 1 | 2 | 3 | 4 | -| :---------: | --- | :-------: | :---: | ----- | -| **FLATMAP** | _2_ | `{a,z}` | `foo` | `bar` | +| 0 | 1 | 2 | 3 | 4 | +| :---------: | --- | :-----: | :---: | ----- | +| **FLATMAP** | 2 | `{a,z}` | `foo` | `bar` | _Table: \#\{a => foo, z => bar\}_ Let us update the map: `M#{q => baz}`. The map now looks like this: -| 0 | 1 | 2 | 3 | 4 | 5 | -| :---------: | --- | :---------: | :---: | :---: | :---: | -| **FLATMAP** | _3_ | `{a,q,z}` | `foo` | `baz` | `bar` | +| 0 | 1 | 2 | 3 | 4 | 5 | +| :---------: | --- | :-------: | :---: | :---: | :---: | +| **FLATMAP** | 3 | `{a,q,z}` | `foo` | `baz` | `bar` | _Table: \#\{a => foo, q => baz, z => bar\}_ Finally, change the value of one element: `M#{z := bird}`. The map now looks like this: -| 0 | 1 | 2 | 3 | 4 | 5 | -| :---------: | --- | :---------: | :---: | :---: | :----: | -| **FLATMAP** | _3_ | `{a,q,z}` | `foo` | `baz` | `bird` | +| 0 | 1 | 2 | 3 | 4 | 5 | +| :---------: | --- | :-------: | :---: | :---: | :----: | +| **FLATMAP** | 3 | `{a,q,z}` | `foo` | `baz` | `bird` | _Table: \#\{a => foo, q => baz, z => bird\}_ diff --git a/system/doc/efficiency_guide/profiling.md b/system/doc/efficiency_guide/profiling.md index 44e2e7e4c1e6..8623a80ea018 100644 --- a/system/doc/efficiency_guide/profiling.md +++ b/system/doc/efficiency_guide/profiling.md @@ -173,11 +173,11 @@ module basis. `cprof` has a low performance degradation effect (compared with ### Tool Summary -| _Tool_ | _Results_ | _Size of Result_ | _Effects on Program Execution Time_ | _Records Number of Calls_ | _Records Execution Time_ | _Records Called by_ | _Records Garbage Collection_ | -| ------- | ----------------------------------- | ---------------- | ----------------------------------- | ------------------------- | ------------------------ | ------------------- | ---------------------------- | -| `fprof` | Per process to screen/file | Large | Significant slowdown | Yes | Total and own | Yes | Yes | -| `eprof` | Per process/function to screen/file | Medium | Small slowdown | Yes | Only total | No | No | -| `cprof` | Per module to caller | Small | Small slowdown | Yes | No | No | No | +| Tool | Results | Size of Result | Effects on Program Execution Time | Records Number of Calls | Records Execution Time | Records Called by | Records Garbage Collection | +| ------- | ----------------------------------- | -------------- | --------------------------------- | ----------------------- | ---------------------- | ----------------- | -------------------------- | +| `fprof` | Per process to screen/file | Large | Significant slowdown | Yes | Total and own | Yes | Yes | +| `eprof` | Per process/function to screen/file | Medium | Small slowdown | Yes | Only total | No | No | +| `cprof` | Per module to caller | Small | Small slowdown | Yes | No | No | No | _Table: Tool Summary_ diff --git a/system/doc/reference_manual/character_set.md b/system/doc/reference_manual/character_set.md index 4edbf114daf9..d63f429170b3 100644 --- a/system/doc/reference_manual/character_set.md +++ b/system/doc/reference_manual/character_set.md @@ -28,9 +28,9 @@ character set. This is noticeable in the following ways: escape backslash convention. - Unquoted atoms and variables can use all Latin-1 letters. -| _Octal_ | _Decimal_ |   | _Class_ | +| Octal | Decimal | | Class | | --------- | --------- | ----- | ---------------------- | -| 200 - 237 | 128 - 159 |   | Control characters | +| 200 - 237 | 128 - 159 | | Control characters | | 240 - 277 | 160 - 191 | \- ¿ | Punctuation characters | | 300 - 326 | 192 - 214 | À - Ö | Uppercase letters | | 327 | 215 | × | Punctuation character | diff --git a/system/doc/reference_manual/data_types.md b/system/doc/reference_manual/data_types.md index a7168150a1b3..d0df01878191 100644 --- a/system/doc/reference_manual/data_types.md +++ b/system/doc/reference_manual/data_types.md @@ -742,7 +742,7 @@ Within strings (`"`\-delimited), quoted atoms, and the content of [`~b` and `~s` sigils](data_types.md#sigil), the following escape sequences are recognized: -| _Sequence_ | _Description_ | +| Sequence | Description | | --------------------------- | ------------------------------------------------------------------------------------- | | `\b` | Backspace (ASCII code 8) | | `\d` | Delete (ASCII code 127) | diff --git a/system/doc/reference_manual/distributed.md b/system/doc/reference_manual/distributed.md index e9daf5de6459..985518f42963 100644 --- a/system/doc/reference_manual/distributed.md +++ b/system/doc/reference_manual/distributed.md @@ -295,7 +295,7 @@ _Table: Distribution BIFs_ Examples of command-line flags used for distributed programming (for more information, see the [erl](`e:erts:erl_cmd.md`) executable in ERTS): -| _Command-Line Flag_ | _Description_ | +| Command-Line Flag | Description | | ------------------------ | ----------------------------------------------------------- | | `-connect_all false` | Only explicit connection setups are used. | | `-hidden` | Makes a node into a hidden node. | @@ -310,7 +310,7 @@ _Table: Distribution Command-Line Flags_ Examples of modules useful for distributed programming in the Kernel application: -| _Module_ | _Description_ | +| Module | Description | | ---------------- | -------------------------------------------------- | | `m:global` | A global name registration facility. | | `m:global_group` | Grouping nodes to global name registration groups. | @@ -321,8 +321,8 @@ _Table: Kernel Modules Useful For Distribution._ In the STDLIB application: -| _Module_ | _Description_ | -| -------- | --------------------------------- | -| `m:peer` | Start and control of peer nodes. | +| Module | Description | +| -------- | -------------------------------- | +| `m:peer` | Start and control of peer nodes. | _Table: STDLIB Modules Useful For Distribution._ diff --git a/system/doc/reference_manual/errors.md b/system/doc/reference_manual/errors.md index 70d5659ed64f..a167962d7d05 100644 --- a/system/doc/reference_manual/errors.md +++ b/system/doc/reference_manual/errors.md @@ -63,11 +63,11 @@ distinguish between the different classes, whereas the [catch](expressions.md#catch-and-throw) expression cannot. `try` and `catch` are described in [Expressions](expressions.md). -| _Class_ | _Origin_ | -| ------- | ---------------------------------------------------------------------------------- | -| `error` | Run-time error, for example, `1+a`, or the process called [`error/1`](`error/1`) | -| `exit` | The process called [`exit/1`](`exit/1`) | -| `throw` | The process called [`throw/1`](`throw/1`) | +| Class | Origin | +| ------- | -------------------------------------------------------------------------------- | +| `error` | Run-time error, for example, `1+a`, or the process called [`error/1`](`error/1`) | +| `exit` | The process called [`exit/1`](`exit/1`) | +| `throw` | The process called [`throw/1`](`throw/1`) | _Table: Exception Classes._ diff --git a/system/doc/reference_manual/expressions.md b/system/doc/reference_manual/expressions.md index bc1b51683afb..03666cc63199 100644 --- a/system/doc/reference_manual/expressions.md +++ b/system/doc/reference_manual/expressions.md @@ -788,16 +788,16 @@ ERTS User's guide. Expr1 op Expr2 ``` -| _op_ | _Description_ | -| ------ | ------------------------ | -| `==` | Equal to | -| `/=` | Not equal to | -| `=<` | Less than or equal to | -| `<` | Less than | -| `>=` | Greater than or equal to | -| `>` | Greater than | -| `=:=` | Term equivalence | -| `=/=` | Term non-equivalence | +| op | Description | +| ----- | ------------------------ | +| `==` | Equal to | +| `/=` | Not equal to | +| `=<` | Less than or equal to | +| `<` | Less than | +| `>=` | Greater than or equal to | +| `>` | Greater than | +| `=:=` | Term equivalence | +| `=/=` | Term non-equivalence | _Table: Term Comparison Operators._ @@ -899,22 +899,22 @@ op Expr Expr1 op Expr2 ``` -| _Operator_ | _Description_ | _Argument Type_ | -| ------------ | ------------------------- | --------------- | -| `+` | Unary + | Number | -| `-` | Negation (unary -) | Number | -| `+` | Addition | Number | -| `-` | Subtraction | Number | -| `*` | Multiplication | Number | -| `/` | Floating point division | Number | -| `bnot` | Unary bitwise NOT | Integer | -| `div` | Integer division | Integer | -| `rem` | Integer remainder of X/Y | Integer | -| `band` | Bitwise AND | Integer | -| `bor` | Bitwise OR | Integer | -| `bxor` | Bitwise XOR | Integer | -| `bsl` | Bitshift left | Integer | -| `bsr` | Arithmetic bitshift right | Integer | +| Operator | Description | Argument Type | +| -------- | ------------------------- | ------------- | +| `+` | Unary + | Number | +| `-` | Negation (unary -) | Number | +| `+` | Addition | Number | +| `-` | Subtraction | Number | +| `*` | Multiplication | Number | +| `/` | Floating point division | Number | +| `bnot` | Unary bitwise NOT | Integer | +| `div` | Integer division | Integer | +| `rem` | Integer remainder of X/Y | Integer | +| `band` | Bitwise AND | Integer | +| `bor` | Bitwise OR | Integer | +| `bxor` | Bitwise XOR | Integer | +| `bsl` | Bitshift left | Integer | +| `bsr` | Arithmetic bitshift right | Integer | _Table: Arithmetic Operators._ @@ -954,12 +954,12 @@ op Expr Expr1 op Expr2 ``` -| _Operator_ | _Description_ | -| ---------- | ----------------- | -| `not` | Unary logical NOT | -| `and` | Logical AND | -| `or` | Logical OR | -| `xor` | Logical XOR | +| Operator | Description | +| -------- | ----------------- | +| `not` | Unary logical NOT | +| `and` | Logical AND | +| `or` | Logical OR | +| `xor` | Logical XOR | _Table: Logical Operators._ @@ -2201,7 +2201,7 @@ Valid guard expressions are the following: - Boolean expressions - Short-circuit expressions (`andalso`/`orelse`) -| _BIF_ | +| BIF | | ------------------------------------ | | [`is_atom/1`](`is_atom/1`) | | [`is_binary/1`](`is_binary/1`) | @@ -2229,7 +2229,7 @@ compatibility and are not to be used in new code. They are also only allowed at top level. For example, they are not allowed in Boolean expressions in guards. -| _BIF_ | +| BIF | | ---------------------------------------- | | [`abs(Number)`](`abs/1`) | | [`bit_size(Bitstring)`](`bit_size/1`) | @@ -2270,19 +2270,19 @@ fails. If the guard was part of a guard sequence, the next guard in the sequence Operator precedence in descending order: -| _Operator_ | _Association_ | -| -------------------------------------------- | ----------------- | -| `#` |   | -| Unary `+` `-` `bnot` `not` |   | -| `/` `*` `div` `rem` `band` `and` | Left-associative | -| `+` `-` `bor` `bxor` `bsl` `bsr` `or` `xor` | Left-associative | -| `++` `--` | Right-associative | -| `==` `/=` `=<` `<` `>=` `>` `=:=` `=/=` | Non-associative | -| `andalso` | Left-associative | -| `orelse` | Left-associative | -| `catch` |   | -| `=` `!` | Right-associative | -| `?=` | Non-associative | +| Operator | Association | +| ------------------------------------------- | ----------------- | +| `#` | | +| Unary `+` `-` `bnot` `not` | | +| `/` `*` `div` `rem` `band` `and` | Left-associative | +| `+` `-` `bor` `bxor` `bsl` `bsr` `or` `xor` | Left-associative | +| `++` `--` | Right-associative | +| `==` `/=` `=<` `<` `>=` `>` `=:=` `=/=` | Non-associative | +| `andalso` | Left-associative | +| `orelse` | Left-associative | +| `catch` | | +| `=` `!` | Right-associative | +| `?=` | Non-associative | _Table: Operator Precedence_ diff --git a/system/doc/reference_manual/ref_man_processes.md b/system/doc/reference_manual/ref_man_processes.md index 7d6091421021..2fdf3f951fe1 100644 --- a/system/doc/reference_manual/ref_man_processes.md +++ b/system/doc/reference_manual/ref_man_processes.md @@ -55,7 +55,7 @@ Besides addressing a process by using its pid, there are also BIFs for registering a process under a name. The name must be an atom and is automatically unregistered if the process terminates: -| _BIF_ | _Description_ | +| BIF | Description | | ------------------------------------- | -------------------------------------------------------------------------------------- | | [`register(Name, Pid)`](`register/2`) | Associates the name `Name`, an atom, with the process `Pid`. | | `registered/0` | Returns a list of names that have been registered using [`register/2`](`register/2`). | diff --git a/system/doc/reference_manual/typespec.md b/system/doc/reference_manual/typespec.md index 07931e81f062..be0eab6219db 100644 --- a/system/doc/reference_manual/typespec.md +++ b/system/doc/reference_manual/typespec.md @@ -192,7 +192,7 @@ predefined aliases for the type unions also shown in the table. [](){: #builtin_types } -| _Built-in type_ | _Defined as_ | +| Built-in type | Defined as | | ------------------------- | --------------------------------------------------------------------------- | | `t:term/0` | `t:any/0` | | `t:binary/0` | `<<_:_*8>>` | @@ -227,11 +227,11 @@ In addition, the following three built-in types exist and can be thought as defined below, though strictly their "type definition" is not valid syntax according to the type language defined above. -| _Built-in type_ | _Can be thought defined by the syntax_ | -| --------------------- | -------------------------------------- | -| `t:non_neg_integer/0` | `0..` | -| `t:pos_integer/0` | `1..` | -| `t:neg_integer/0` | `..-1` | +| Built-in type | Can be thought defined by the syntax | +| --------------------- | ------------------------------------ | +| `t:non_neg_integer/0` | `0..` | +| `t:pos_integer/0` | `1..` | +| `t:neg_integer/0` | `..-1` | _Table: Additional built-in types_ diff --git a/system/doc/system_principles/system_principles.md b/system/doc/system_principles/system_principles.md index 539527ec7d67..95318585fcfe 100644 --- a/system/doc/system_principles/system_principles.md +++ b/system/doc/system_principles/system_principles.md @@ -195,16 +195,16 @@ querying the search path. The following file types are defined in Erlang/OTP: -| _File Type_ | _File Name/Extension_ | _Documented in_ | -| ------------------------- | --------------------- | --------------------------------------------------- | -| Module | `.erl` | [Erlang Reference Manual](`e:system:modules.md`) | -| Include file | `.hrl` | [Erlang Reference Manual](`e:system:modules.md`) | -| Release resource file | `.rel` | [rel](`e:sasl:rel.md`) in SASL | -| Application resource file | `.app` | [app](`e:kernel:app.md`) in Kernel | -| Boot script | `.script` | [script](`e:sasl:script.md`) in SASL | -| Binary boot script | `.boot` | - | -| Configuration file | `.config` | [config](`e:kernel:config.md`) in Kernel | -| Application upgrade file | `.appup` | [appup](`e:sasl:appup.md`) in SASL | -| Release upgrade file | `relup` | [relup](`e:sasl:relup.md`) in SASL | +| File Type | File Name/Extension | Documented in | +| ------------------------- | ------------------- | ------------------------------------------------ | +| Module | `.erl` | [Erlang Reference Manual](`e:system:modules.md`) | +| Include file | `.hrl` | [Erlang Reference Manual](`e:system:modules.md`) | +| Release resource file | `.rel` | [rel](`e:sasl:rel.md`) in SASL | +| Application resource file | `.app` | [app](`e:kernel:app.md`) in Kernel | +| Boot script | `.script` | [script](`e:sasl:script.md`) in SASL | +| Binary boot script | `.boot` | - | +| Configuration file | `.config` | [config](`e:kernel:config.md`) in Kernel | +| Application upgrade file | `.appup` | [appup](`e:sasl:appup.md`) in SASL | +| Release upgrade file | `relup` | [relup](`e:sasl:relup.md`) in SASL | _Table: File Types_