Change:
Update reference.
Almost, but I think I can accept my own suggestions so I'll just do that and merge.

Discussion:
certificate chain. This document describes a mechanism that would allow certificates to <del> be compressed during full handshakes. </del> <ins> be compressed during all handshakes. </ins> 2.

for decompression.  The "extension_data" field of this extension SHALL contain a CertificateCompressionAlgorithms value: <del> There is no ServerHello extension that the server is required to echo back. </del> <ins> The compress_certificate extension is a unidirectional indication; no corresponding response extension is needed. </ins> 4.

uncompressed Certificate message and to enforce limits on the message size before performing decompression. <del> The compressed body of the Certificate message, in the same format as it would normally be expressed in.  The compression algorithm </del> <ins> The result of applying the indicated compression algorithm to the encoded Certificate message that would have been sent if certificate compression was not in use.  The compression algorithm </ins> defines how the bytes in the compressed_certificate_message field are converted into the Certificate message.

It is possible to define a certificate compression algorithm that uses a pre-shared dictionary to achieve higher compression ratio. <del> This document does not define any such algorithms. </del> <ins> This document does not define any such algorithms, but additional codepoints may be allocated for such use per the policy in registry. </ins> If the received CompressedCertificate message cannot be decompressed, <del> the connection MUST be torn down with the "bad_certificate" alert. </del> <ins> the connection MUST be terminated with the "bad_certificate" alert. </ins> If the format of the Certificate message is altered using the server_certificate_type or client_certificate_type extensions

in TLS normally. In order for certificate compression to function correctly, the <del> underlying compression algorithm MUST be deterministic and it MUST output the same data that was provided as input by the peer. </del> <ins> underlying compression algorithm MUST output the same data that was provided as input by the peer. </ins> Since certificate chains are typically presented on a per-server name <del> or per-user basis, the attacker does not have control over any individual fragments in the Certificate message, meaning that they cannot leak information about the certificate by modifying the </del> <ins> or per-user basis, a malicious application does not have control over any individual fragments in the Certificate message, meaning that they cannot leak information about the certificate by modifying the </ins> plaintext. <del> The implementations SHOULD bound the memory usage when decompressing the CompressedCertificate message. </del> <ins> Implementations SHOULD bound the memory usage when decompressing the CompressedCertificate message. </ins> <del> The implementations MUST limit the size of the resulting decompressed </del> <ins> Implementations MUST limit the size of the resulting decompressed </ins> chain to the specified uncompressed length, and they MUST abort the <del> connection if the size exceeds that limit.  TLS framing imposes 16777216 byte limit on the certificate message size, and the implementations MAY impose a limit that is lower than that; in both cases, they MUST apply the same limit as if no compression were used. </del> <ins> connection if the size of the output of the decompression function exceeds that limit.  TLS framing imposes 16777216 byte limit on the certificate message size, and the implementations MAY impose a limit that is lower than that; in both cases, they MUST apply the same limit as if no compression were used. </ins> 6.