target = "https://tools.ietf.org/rfc/rfc8446#6.1"

# 6.1.  Closure Alerts
#
# The client and the server must share knowledge that the connection is
# ending in order to avoid a truncation attack.
# 
# close_notify:  This alert notifies the recipient that the sender will
#    not send any more messages on this connection.  Any data received
#    after a closure alert has been received MUST be ignored.
# 
# user_canceled:  This alert notifies the recipient that the sender is
#    canceling the handshake for some reason unrelated to a protocol
#    failure.  If a user cancels an operation after the handshake is
#    complete, just closing the connection by sending a "close_notify"
#    is more appropriate.  This alert SHOULD be followed by a
#    "close_notify".  This alert generally has AlertLevel=warning.
# 
# Either party MAY initiate a close of its write side of the connection
# by sending a "close_notify" alert.  Any data received after a closure
# alert has been received MUST be ignored.  If a transport-level close
# is received prior to a "close_notify", the receiver cannot know that
# all the data that was sent has been received.
# 
# Each party MUST send a "close_notify" alert before closing its write
# side of the connection, unless it has already sent some error alert.
# This does not have any effect on its read side of the connection.
# Note that this is a change from versions of TLS prior to TLS 1.3 in
# which implementations were required to react to a "close_notify" by
# discarding pending writes and sending an immediate "close_notify"
# alert of their own.  That previous requirement could cause truncation
# in the read side.  Both parties need not wait to receive a
# "close_notify" alert before closing their read side of the
# connection, though doing so would introduce the possibility of
# truncation.
# 
# If the application protocol using TLS provides that any data may be
# carried over the underlying transport after the TLS connection is
# closed, the TLS implementation MUST receive a "close_notify" alert
# before indicating end-of-data to the application layer.  No part of
# this standard should be taken to dictate the manner in which a usage
# profile for TLS manages its data transport, including when
# connections are opened or closed.
# 
# Note: It is assumed that closing the write side of a connection
# reliably delivers pending data before destroying the transport.

[[spec]]
level = "MUST"
quote = '''
Any data received
after a closure alert has been received MUST be ignored.
'''

[[spec]]
level = "SHOULD"
quote = '''
This alert SHOULD be followed by a
"close_notify".
'''

[[spec]]
level = "MAY"
quote = '''
Either party MAY initiate a close of its write side of the connection
by sending a "close_notify" alert.
'''

[[spec]]
level = "MUST"
quote = '''
Any data received after a closure
alert has been received MUST be ignored.
'''

[[spec]]
level = "MUST"
quote = '''
Each party MUST send a "close_notify" alert before closing its write
side of the connection, unless it has already sent some error alert.
'''

[[spec]]
level = "MUST"
quote = '''
If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is
closed, the TLS implementation MUST receive a "close_notify" alert
before indicating end-of-data to the application layer.
'''