Diff: rfc9530.original.xml

	rfc9530.original.xml	rfc9530.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version="1.0" encoding="UTF-8"?>

	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.36 (Ruby 3.2.	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	2) -->	-ietf-httpbis-digest-headers-13" number="9530" submissionType="IETF" category="s
	<?rfc tocindent="yes"?>	td" consensus="true" updates="" obsoletes="3230" tocInclude="true" sortRefs="tru
	<?rfc strict="yes"?>	e" symRefs="true" xml:lang="en" version="3">
	<?rfc compact="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc docmapping="yes"?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-ietf-httpbis-digest-headers-13" category="std" consensus="true" obsoletes="3230
	" tocInclude="true" sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.17.4 -->	<!-- xml2rfc v2v3 conversion 3.17.4 -->
	<front>	<front>
	<title>Digest Fields</title>	<title>Digest Fields</title>

	<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-digest-headers-1 3"/>	<seriesInfo name="RFC" value="9530"/>
	<author initials="R." surname="Polli" fullname="Roberto Polli">	<author initials="R." surname="Polli" fullname="Roberto Polli">
	<organization>Team Digitale, Italian Government</organization>	<organization>Team Digitale, Italian Government</organization>
	<address>	<address>
	<postal>	<postal>
	<country>Italy</country>	<country>Italy</country>
	</postal>	</postal>
	<email>robipolli@gmail.com</email>	<email>robipolli@gmail.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="L." surname="Pardue" fullname="Lucas Pardue">	<author initials="L." surname="Pardue" fullname="Lucas Pardue">
	<organization>Cloudflare</organization>	<organization>Cloudflare</organization>
	<address>	<address>

	<email>lucaspardue.24.7@gmail.com</email>	<email>lucas@lucaspardue.com</email>
	</address>	</address>
	</author>	</author>

	<date year="2023" month="July" day="10"/>	<date month="February" year="2024"/>
	<area>Applications and Real-Time</area>	<area>Applications and Real-Time</area>
	<workgroup>HTTP</workgroup>	<workgroup>HTTP</workgroup>
	<keyword>Digest</keyword>	<keyword>Digest</keyword>
	<abstract>	<abstract>

	<?line 87?>

	<t>This document defines HTTP fields that support integrity digests. The	<t>This document defines HTTP fields that support integrity digests. The

	Content-Digest field can be used for the integrity of HTTP message content. The	<tt>Content-Digest</tt> field can be used for the integrity of HTTP message cont
	Repr-Digest field can be used for the integrity of HTTP representations.	ent. The
	Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's	<tt>Repr-Digest</tt> field can be used for the integrity of HTTP representations
		.
		<tt>Want-Content-Digest</tt> and <tt>Want-Repr-Digest</tt> can be used to indica
		te a sender's
	interest and preferences for receiving the respective Integrity fields.</t>	interest and preferences for receiving the respective Integrity fields.</t>

	<t>This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP	<t>This document obsoletes RFC 3230 and the <tt>Digest</tt> and <tt>Want-D igest</tt> HTTP
	fields.</t>	fields.</t>
	</abstract>	</abstract>

	<note removeInRFC="true">
	<name>About This Document</name>
	<t>
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.or
	g"/>),
	which is archived at <eref target="https://lists.w3.org/Archives/Public/
	ietf-http-wg/"/>.
	Working Group information can be found at <eref target="https://httpwg.o
	rg/"/>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/httpwg/http-extensions/labels/digest-he
	aders"/>.</t>
	</note>
	</front>	</front>
	<middle>	<middle>

	<?line 99?>

	<section anchor="introduction">	<section anchor="introduction">
	<name>Introduction</name>	<name>Introduction</name>
	<t>HTTP does not define the means to protect the data integrity of content or	<t>HTTP does not define the means to protect the data integrity of content or

	representations. When HTTP messages are transferred between endpoints, lower lay	representations. When HTTP messages are transferred between endpoints, lower-lay
	er	er
	features or properties such as TCP checksums or TLS records <xref target="TLS"/>	features or properties such as TCP checksums or TLS records <xref target="RFC844
	can provide	6"/> can provide some integrity protection. However, transport-oriented integrit
	some integrity protection. However, transport-oriented integrity provides a	y provides a
	limited utility because it is opaque to the application layer and only covers	limited utility because it is opaque to the application layer and only covers
	the extent of a single connection. HTTP messages often travel over a chain of	the extent of a single connection. HTTP messages often travel over a chain of

	separate connections. In between connections there is a possibility for	separate connections. In between connections, there is a possibility for
	data corruption. An HTTP integrity mechanism can provide	data corruption. An HTTP integrity mechanism can provide
	the means for endpoints, or applications using HTTP, to detect data corruption	the means for endpoints, or applications using HTTP, to detect data corruption
	and make a choice about how to act on it. An example use case is to aid	and make a choice about how to act on it. An example use case is to aid
	fault detection and diagnosis across system boundaries.</t>	fault detection and diagnosis across system boundaries.</t>
	<t>This document defines two digest integrity mechanisms for HTTP.	<t>This document defines two digest integrity mechanisms for HTTP.
	First, content integrity, which acts on conveyed content (<xref section="6.4" se ctionFormat="of" target="RFC9110"/>).	First, content integrity, which acts on conveyed content (<xref section="6.4" se ctionFormat="of" target="RFC9110"/>).

	Second, representation data integrity, which acts on representation data (<xref section="8.1" sectionFormat="of" target="RFC9110"/>). This supports advanced use cases such as validating the	Second, representation data integrity, which acts on representation data (<xref section="8.1" sectionFormat="of" target="RFC9110"/>). This supports advanced use cases, such as validating the
	integrity of a resource that was reconstructed from parts retrieved using	integrity of a resource that was reconstructed from parts retrieved using
	multiple requests or connections.</t>	multiple requests or connections.</t>

	<t>This document obsoletes RFC 3230 and therefore the Digest and Want-Dige st HTTP	<t>This document obsoletes <xref target="RFC3230"/> and therefore the <tt> Digest</tt> and <tt>Want-Digest</tt> HTTP
	fields; see <xref target="obsolete-3230"/>.</t>	fields; see <xref target="obsolete-3230"/>.</t>
	<section anchor="document-structure">	<section anchor="document-structure">
	<name>Document Structure</name>	<name>Document Structure</name>
	<t>This document is structured as follows:</t>	<t>This document is structured as follows:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>New request and response header and trailer field definitions.	<t>New request and response header and trailer field definitions.
	</t>	</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<xref target="content-digest"/> (Content-Digest),</li>	<xref target="content-digest"/> (<tt>Content-Digest</tt>),</li>
	<li>	<li>

	<xref target="representation-digest"/> (Repr-Digest), and</li>	<xref target="representation-digest"/> (<tt>Repr-Digest</tt>), a nd</li>
	<li>	<li>

	<xref target="want-fields"/> (Want-Content-Digest and Want-Repr- Digest).</li>	<xref target="want-fields"/> (<tt>Want-Content-Digest</tt> and < tt>Want-Repr-Digest</tt>).</li>
	</ul>	</ul>
	</li>	</li>
	<li>	<li>
	<t>Considerations specific to representation data integrity.	<t>Considerations specific to representation data integrity.
	</t>	</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<xref target="state-changing-requests"/> (State-changing request s),</li>	<xref target="state-changing-requests"/> (State-changing request s),</li>
	<li>	<li>
	<xref target="digest-and-content-location"/> (Content-Location), </li>	<xref target="digest-and-content-location"/> (Content-Location), </li>
	<li>	<li>

	<xref target="resource-representation"/> contains worked example s of Representation data	<xref target="resource-representation"/> contains worked example s of representation data
	in message exchanges, and</li>	in message exchanges, and</li>
	<li>	<li>

	<xref target="examples-unsolicited"/> and <xref target="examples	Appendixes <xref target="examples-unsolicited" format="counter"/
	-solicited"/> contain worked examples	> and <xref target="examples-solicited" format="counter"/> contain worked exampl
	of Repr-Digest and Want-Repr-Digest fields in message exchanges.</li>	es
		of <tt>Repr-Digest</tt> and <tt>Want-Repr-Digest</tt> fields in message exchange
		s.</li>
	</ul>	</ul>
	</li>	</li>
	<li>	<li>
	<xref target="algorithms"/> presents hash algorithm considerations a nd defines	<xref target="algorithms"/> presents hash algorithm considerations a nd defines
	registration procedures for future entries.</li>	registration procedures for future entries.</li>
	</ul>	</ul>
	</section>	</section>
	<section anchor="concept-overview">	<section anchor="concept-overview">
	<name>Concept Overview</name>	<name>Concept Overview</name>
	<t>The HTTP fields defined in this document can be used for HTTP integri ty. Senders	<t>The HTTP fields defined in this document can be used for HTTP integri ty. Senders

	skipping to change at line 144 ¶	skipping to change at line 120 ¶
	<t>Selecting the data on which digests are calculated depends on the use case of the	<t>Selecting the data on which digests are calculated depends on the use case of the
	HTTP messages. This document provides different fields for HTTP representation	HTTP messages. This document provides different fields for HTTP representation
	data and HTTP content.</t>	data and HTTP content.</t>
	<t>There are use cases where a simple digest of the HTTP content bytes i s	<t>There are use cases where a simple digest of the HTTP content bytes i s
	required. The <tt>Content-Digest</tt> request and response header and trailer fi eld is	required. The <tt>Content-Digest</tt> request and response header and trailer fi eld is
	defined to support digests of content (<xref section="6.4" sectionFormat="of" ta rget="RFC9110"/>); see	defined to support digests of content (<xref section="6.4" sectionFormat="of" ta rget="RFC9110"/>); see
	<xref target="content-digest"/>.</t>	<xref target="content-digest"/>.</t>
	<t>For more advanced use cases, the <tt>Repr-Digest</tt> request and res ponse header	<t>For more advanced use cases, the <tt>Repr-Digest</tt> request and res ponse header
	and trailer field (<xref target="representation-digest"/>) is defined. It contai ns a digest value	and trailer field (<xref target="representation-digest"/>) is defined. It contai ns a digest value
	computed by applying a hashing algorithm to selected representation data	computed by applying a hashing algorithm to selected representation data

	(<xref section="8.1" sectionFormat="of" target="RFC9110"/>). Basing <tt>Repr-Dig	(<xref section="8.1" sectionFormat="of" target="RFC9110"/>).
	est</tt> on the selected
		Basing <tt>Repr-Digest</tt> on the selected
	representation makes it straightforward to apply it to use cases where the	representation makes it straightforward to apply it to use cases where the
	message content requires some sort of manipulation to be considered as	message content requires some sort of manipulation to be considered as

	representation of the resource or content conveys a partial representation of a	representation of the resource or the content conveys a partial representation o
	resource,	f a resource,
	such as Range Requests (see <xref section="14" sectionFormat="of" target="RFC911	such as range requests (see <xref section="14" sectionFormat="of" target="RFC911
	0"/>).</t>	0"/>).</t>
	<t><tt>Content-Digest</tt> and <tt>Repr-Digest</tt> support hashing algo	<t><tt>Content-Digest</tt> and <tt>Repr-Digest</tt> support hashing algorithm ag
	rithm agility.	ility.
	The <tt>Want-Content-Digest</tt> and <tt>Want-Repr-Digest</tt> fields allow	The <tt>Want-Content-Digest</tt> and <tt>Want-Repr-Digest</tt> fields allow

	endpoints to express interest in <tt>Content-Digest</tt> and <tt>Repr-Digest</tt	endpoints to express interest in <tt>Content-Digest</tt> and <tt>Repr-Digest</tt
	>	>, respectively, and to express algorithm preferences in either.</t>
	respectively, and to express algorithm preferences in either.</t>
	<t><tt>Content-Digest</tt> and <tt>Repr-Digest</tt> are collectively ter med	<t><tt>Content-Digest</tt> and <tt>Repr-Digest</tt> are collectively ter med

	Integrity fields.	"Integrity fields".
	<tt>Want-Content-Digest</tt> and <tt>Want-Repr-Digest</tt> are	<tt>Want-Content-Digest</tt> and <tt>Want-Repr-Digest</tt> are

	collectively termed Integrity preference fields.</t>	collectively termed "Integrity preference fields".</t>
	<t>Integrity fields are tied to the <tt>Content-Encoding</tt>	<t>Integrity fields are tied to the <tt>Content-Encoding</tt>
	and <tt>Content-Type</tt> header fields. Therefore, a given resource may have mu ltiple	and <tt>Content-Type</tt> header fields. Therefore, a given resource may have mu ltiple
	different digest values when transferred with HTTP.</t>	different digest values when transferred with HTTP.</t>
	<t>Integrity fields apply to HTTP message content or HTTP representation s. They do	<t>Integrity fields apply to HTTP message content or HTTP representation s. They do
	not apply to HTTP messages or fields. However, they can be combined with other	not apply to HTTP messages or fields. However, they can be combined with other
	mechanisms that protect metadata, such as digital signatures, in order to	mechanisms that protect metadata, such as digital signatures, in order to
	protect the phases of an HTTP exchange in whole or in part. For example, HTTP	protect the phases of an HTTP exchange in whole or in part. For example, HTTP

	Message Signatures <xref target="SIGNATURES"/> could be used to sign Integrity f ields, thus	Message Signatures <xref target="RFC9421"/> could be used to sign Integrity fiel ds, thus
	providing coverage for HTTP content or representation data.</t>	providing coverage for HTTP content or representation data.</t>
	<t>This specification does not define means for authentication, authoriz ation, or privacy.</t>	<t>This specification does not define means for authentication, authoriz ation, or privacy.</t>
	</section>	</section>
	<section anchor="obsolete-3230">	<section anchor="obsolete-3230">
	<name>Obsoleting RFC 3230</name>	<name>Obsoleting RFC 3230</name>
	<t><xref target="RFC3230"/> defined the <tt>Digest</tt> and <tt>Want-Dig est</tt> HTTP fields for HTTP integrity.	<t><xref target="RFC3230"/> defined the <tt>Digest</tt> and <tt>Want-Dig est</tt> HTTP fields for HTTP integrity.

	It also coined the term "instance" and "instance manipulation" in order to	It also coined the terms "instance" and "instance manipulation" in order to
	explain concepts that are now more universally defined, and implemented, as HTTP	explain concepts, such as selected representation data (<xref section="8.1"
	semantics such as selected representation data (<xref section="8.1" sectionForma	sectionFormat="of" target="RFC9110"/>), that are now more universally defined an
	t="of" target="RFC9110"/>).</t>	d implemented as HTTP
		semantics.</t>
	<t>Experience has shown that implementations of <xref target="RFC3230"/> have interpreted the	<t>Experience has shown that implementations of <xref target="RFC3230"/> have interpreted the
	meaning of "instance" inconsistently, leading to interoperability issues. The	meaning of "instance" inconsistently, leading to interoperability issues. The
	most common issue relates to the mistake of calculating the digest using (what	most common issue relates to the mistake of calculating the digest using (what
	we now call) message content, rather than using (what we now call)	we now call) message content, rather than using (what we now call)
	representation data as was originally intended. Interestingly, time has also	representation data as was originally intended. Interestingly, time has also

	shown that a digest of message content can be beneficial for some use cases. So	shown that a digest of message content can be beneficial for some use cases, so
	it is difficult to detect if non-conformance to <xref target="RFC3230"/> is inte ntional or	it is difficult to detect if non-conformance to <xref target="RFC3230"/> is inte ntional or
	unintentional.</t>	unintentional.</t>
	<t>In order to address potential inconsistencies and ambiguity across	<t>In order to address potential inconsistencies and ambiguity across
	implementations of <tt>Digest</tt> and <tt>Want-Digest</tt>, this document obsol etes	implementations of <tt>Digest</tt> and <tt>Want-Digest</tt>, this document obsol etes
	<xref target="RFC3230"/>. The Integrity fields (Sections <xref format="counter" target="content-digest"/> and	<xref target="RFC3230"/>. The Integrity fields (Sections <xref format="counter" target="content-digest"/> and
	<xref format="counter" target="representation-digest"/>) and Integrity preferenc e fields (<xref target="want-fields"/>)	<xref format="counter" target="representation-digest"/>) and Integrity preferenc e fields (<xref target="want-fields"/>)
	defined in this document are better aligned with current HTTP semantics and	defined in this document are better aligned with current HTTP semantics and
	have names that more clearly articulate the intended usages.</t>	have names that more clearly articulate the intended usages.</t>
	</section>	</section>
	<section anchor="notational-conventions">	<section anchor="notational-conventions">
	<name>Notational Conventions</name>	<name>Notational Conventions</name>

	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp	<t>
	14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	nterpreted as	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and	be interpreted as
	only when, they	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	appear in all capitals, as shown here.</t>	when, and only when, they appear in all capitals, as shown here.
		</t>
	<?line -18?>	<?line -18?>


	<t>This document uses the Augmented BNF defined in <xref target="RFC5234"/> and updated by	<t>This document uses the Augmented BNF defined in <xref target="RFC5234"/> and updated by

	<xref target="RFC7405"/>. This includes the rules: CR (carriage	<xref target="RFC7405"/>. This includes the rules CR (carriage return), LF (line
	return), LF (line feed), and CRLF (CR LF).</t>	feed), and CRLF (CR LF).</t>
	<t>This document uses the following terminology from <xref section="3" s	<t>This document uses the following terminology from <xref section="3" s
	ectionFormat="of" target="STRUCTURED-FIELDS"/> to specify syntax and parsing:	ectionFormat="of" target="RFC8941"/> to specify syntax and parsing:
	Boolean, Byte Sequence, Dictionary, Integer, and List.</t>	Boolean, Byte Sequence, Dictionary, Integer, and List.</t>
	<t>The definitions "representation", "selected representation", "represe ntation	<t>The definitions "representation", "selected representation", "represe ntation
	data", "representation metadata", "user agent", and "content" in this document a re to be	data", "representation metadata", "user agent", and "content" in this document a re to be
	interpreted as described in <xref target="RFC9110"/>.</t>	interpreted as described in <xref target="RFC9110"/>.</t>
	<t>This document uses the line folding strategies	<t>This document uses the line folding strategies

	described in <xref target="FOLDING"/>.</t>	described in <xref target="RFC8792"/>.</t>
	<t>Hashing algorithm names respect the casing used in their definition d ocument (e.g., SHA-1, CRC32c).</t>	<t>Hashing algorithm names respect the casing used in their definition d ocument (e.g., SHA-1, CRC32c).</t>
	<t>HTTP messages indicate hashing algorithms using an Algorithm Key (<co ntact fullname="algorithms"/>).	<t>HTTP messages indicate hashing algorithms using an Algorithm Key (<co ntact fullname="algorithms"/>).
	Where the document refers to an Algorithm Key in prose, it is quoted (e.g., "sha ", "crc32c").</t>	Where the document refers to an Algorithm Key in prose, it is quoted (e.g., "sha ", "crc32c").</t>

	<t>The term "checksum" describes the output of the application of an alg
	orithm	<t>The term "checksum" describes the output of applying an algorithm
	to a sequence of bytes,	to a sequence of bytes, whereas "digest" is only used in relation to
	whereas "digest" is only used in relation to the value contained in the fields.<	the value contained in the fields.</t>
	/t>	<t>"Integrity fields" is the collective term for <tt>Content-Digest</tt> and
	<t>Integrity fields: collective term for <tt>Content-Digest</tt> and <tt	<tt>Repr-Digest</tt>.</t>
	>Repr-Digest</tt></t>	<t>"Integrity preference fields" is the collective term for <tt>Want-Repr-Digest
	<t>Integrity preference fields: collective term for <tt>Want-Repr-Digest	</tt>
	</tt> and <tt>Want-Content-Digest</tt></t>	and <tt>Want-Content-Digest</tt>.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="content-digest">	<section anchor="content-digest">

	<name>The Content-Digest Field</name>	<name>The <tt>Content-Digest</tt> Field</name>
	<t>The <tt>Content-Digest</tt> HTTP field can be used in requests and resp onses to	<t>The <tt>Content-Digest</tt> HTTP field can be used in requests and resp onses to
	communicate digests that are calculated using a hashing algorithm applied to	communicate digests that are calculated using a hashing algorithm applied to
	the actual message content (see <xref section="6.4" sectionFormat="of" target="R FC9110"/>). It is a	the actual message content (see <xref section="6.4" sectionFormat="of" target="R FC9110"/>). It is a

	<tt>Dictionary</tt> (see <xref section="3.2" sectionFormat="of" target="STRUCTUR ED-FIELDS"/>)	Dictionary (see <xref section="3.2" sectionFormat="of" target="RFC8941"/>),
	where each:</t>	where each:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>key conveys the hashing algorithm (see <xref target="algorithms"/>)	<li>key conveys the hashing algorithm (see <xref target="algorithms"/>)
	used to compute the digest;</li>	used to compute the digest;</li>

	<li>value is a <tt>Byte Sequence</tt> (<xref section="3.3.5" sectionForm at="of" target="STRUCTURED-FIELDS"/>), that	<li>value is a Byte Sequence (<xref section="3.3.5" sectionFormat="of" t arget="RFC8941"/>) that
	conveys an encoded version of the byte output produced by the digest	conveys an encoded version of the byte output produced by the digest
	calculation.</li>	calculation.</li>
	</ul>	</ul>
	<t>For example:</t>	<t>For example:</t>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	Content-Digest: \	Content-Digest: \
	sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\	sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
	yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:	yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
	]]></sourcecode>	]]></sourcecode>

	<t>The <tt>Dictionary</tt> type can be used, for example, to attach multip le digests	<t>The Dictionary type can be used, for example, to attach multiple digest s
	calculated using different hashing algorithms in order to support a population	calculated using different hashing algorithms in order to support a population
	of endpoints with different or evolving capabilities. Such an approach could	of endpoints with different or evolving capabilities. Such an approach could
	support transitions away from weaker algorithms (see <xref target="sec-agility"/ >).</t>	support transitions away from weaker algorithms (see <xref target="sec-agility"/ >).</t>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	Content-Digest: \	Content-Digest: \
	sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\	sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\
	sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\	sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
	yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:	yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
	]]></sourcecode>	]]></sourcecode>
	<t>A recipient <bcp14>MAY</bcp14> ignore any or all digests. Application-s pecific behavior or	<t>A recipient <bcp14>MAY</bcp14> ignore any or all digests. Application-s pecific behavior or
	local policy <bcp14>MAY</bcp14> set additional constraints on the processing and validation	local policy <bcp14>MAY</bcp14> set additional constraints on the processing and validation
	practices of the conveyed digests.	practices of the conveyed digests.

	The security considerations covers some of the issues related to	The security considerations cover some of the issues related to
	ignoring digests (see <xref target="sec-agility"/>)	ignoring digests (see <xref target="sec-agility"/>)
	and validating multiple digests (see <xref target="sec-exhaustion"/>).</t>	and validating multiple digests (see <xref target="sec-exhaustion"/>).</t>
	<t>A sender <bcp14>MAY</bcp14> send a digest without	<t>A sender <bcp14>MAY</bcp14> send a digest without

	knowing whether the recipient supports a given hashing algorithm, or even knowin	knowing whether the recipient supports a given hashing algorithm. A sender <bcp1
	g	4>MAY</bcp14> send a digest if it knows the recipient will ignore it.</t>
	that the recipient will ignore it.</t>
	<t><tt>Content-Digest</tt> can be sent in a trailer section.	<t><tt>Content-Digest</tt> can be sent in a trailer section.
	In this case,	In this case,
	<tt>Content-Digest</tt> <bcp14>MAY</bcp14> be merged into the header section; se e <xref section="6.5.1" sectionFormat="of" target="RFC9110"/>.</t>	<tt>Content-Digest</tt> <bcp14>MAY</bcp14> be merged into the header section; se e <xref section="6.5.1" sectionFormat="of" target="RFC9110"/>.</t>
	</section>	</section>
	<section anchor="representation-digest">	<section anchor="representation-digest">

	<name>The Repr-Digest Field</name>	<name>The <tt>Repr-Digest</tt> Field</name>
	<t>The <tt>Repr-Digest</tt> HTTP field can be used in requests and respons es to	<t>The <tt>Repr-Digest</tt> HTTP field can be used in requests and respons es to
	communicate digests that are calculated using a hashing algorithm applied to	communicate digests that are calculated using a hashing algorithm applied to
	the entire selected representation data (see <xref section="8.1" sectionFormat=" of" target="RFC9110"/>).</t>	the entire selected representation data (see <xref section="8.1" sectionFormat=" of" target="RFC9110"/>).</t>
	<t>Representations take into account the effect of the HTTP semantics on	<t>Representations take into account the effect of the HTTP semantics on

	messages. For example, the content can be affected by Range Requests or methods	messages. For example, the content can be affected by range requests or methods,
	such as HEAD, while the way the content is transferred "on the wire" is	such as HEAD, while the way the content is transferred "on the wire" is
	dependent on other transformations (e.g., transfer codings for HTTP/1.1 - see	dependent on other transformations (e.g., transfer codings for HTTP/1.1; see
	<xref section="6.1" sectionFormat="of" target="RFC9112"/>). To help illustrate H TTP representation concepts,	<xref section="6.1" sectionFormat="of" target="RFC9112"/>). To help illustrate H TTP representation concepts,
	several examples are provided in <xref target="resource-representation"/>.</t>	several examples are provided in <xref target="resource-representation"/>.</t>

	<t>When a message has no representation data it is still possible to asser t that no	<t>When a message has no representation data, it is still possible to asse rt that no
	representation data was sent by computing the digest on an empty	representation data was sent by computing the digest on an empty
	string (see <xref target="usage-in-signatures"/>).</t>	string (see <xref target="usage-in-signatures"/>).</t>

	<t><tt>Repr-Digest</tt> is a <tt>Dictionary</tt> (see <xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS"/>) where each:</t>	<t><tt>Repr-Digest</tt> is a Dictionary (see <xref section="3.2" sectionFo rmat="of" target="RFC8941"/>), where each:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>key conveys the hashing algorithm (see <xref target="algorithms"/>)	<li>key conveys the hashing algorithm (see <xref target="algorithms"/>)
	used to compute the digest;</li>	used to compute the digest;</li>

	<li>value is a <tt>Byte Sequence</tt>, that conveys an encoded version o f the byte	<li>value is a Byte Sequence that conveys an encoded version of the byte
	output produced by the digest calculation.</li>	output produced by the digest calculation.</li>
	</ul>	</ul>
	<t>For example:</t>	<t>For example:</t>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	Repr-Digest: \	Repr-Digest: \
	sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\	sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
	yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:	yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
	]]></sourcecode>	]]></sourcecode>

	<t>The <tt>Dictionary</tt> type can be used, for example, to attach multip le digests	<t>The Dictionary type can be used to attach multiple digests
	calculated using different hashing algorithms in order to support a population	calculated using different hashing algorithms in order to support a population
	of endpoints with different or evolving capabilities. Such an approach could	of endpoints with different or evolving capabilities. Such an approach could
	support transitions away from weaker algorithms (see <xref target="sec-agility"/ >).</t>	support transitions away from weaker algorithms (see <xref target="sec-agility"/ >).</t>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	Repr-Digest: \	Repr-Digest: \
	sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\	sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\
	sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\	sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
	yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:	yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
	]]></sourcecode>	]]></sourcecode>
	<t>A recipient <bcp14>MAY</bcp14> ignore any or all digests. Application-s pecific behavior or	<t>A recipient <bcp14>MAY</bcp14> ignore any or all digests. Application-s pecific behavior or
	local policy <bcp14>MAY</bcp14> set additional constraints on the processing and validation	local policy <bcp14>MAY</bcp14> set additional constraints on the processing and validation
	practices of the conveyed digests.	practices of the conveyed digests.

	The security considerations covers some of the issues related to	The security considerations cover some of the issues related to
	ignoring digests (see <xref target="sec-agility"/>)	ignoring digests (see <xref target="sec-agility"/>)
	and validating multiple digests (see <xref target="sec-exhaustion"/>).</t>	and validating multiple digests (see <xref target="sec-exhaustion"/>).</t>

	<t>A sender <bcp14>MAY</bcp14> send a digest without knowing whether the	<t>A sender <bcp14>MAY</bcp14> send a digest without knowing whether the r
	recipient supports a given hashing algorithm, or even knowing that the recipient	ecipient supports a given hashing algorithm. A sender <bcp14>MAY</bcp14> send a
	will ignore it.</t>	digest if it knows the recipient will ignore it.</t>
	<t><tt>Repr-Digest</tt> can be sent in a trailer section.	<t><tt>Repr-Digest</tt> can be sent in a trailer section.
	In this case,	In this case,
	<tt>Repr-Digest</tt> <bcp14>MAY</bcp14> be merged into the header section; see < xref section="6.5.1" sectionFormat="of" target="RFC9110"/>.</t>	<tt>Repr-Digest</tt> <bcp14>MAY</bcp14> be merged into the header section; see < xref section="6.5.1" sectionFormat="of" target="RFC9110"/>.</t>
	<section anchor="state-changing-requests">	<section anchor="state-changing-requests">

	<name>Using Repr-Digest in State-Changing Requests</name>	<name>Using <tt>Repr-Digest</tt> in State-Changing Requests</name>
	<t>When the representation enclosed in a state-changing request	<t>When the representation enclosed in a state-changing request
	does not describe the target resource,	does not describe the target resource,
	the representation digest <bcp14>MUST</bcp14> be computed on the	the representation digest <bcp14>MUST</bcp14> be computed on the
	representation data.	representation data.
	This is the only possible choice because representation digest requires complete	This is the only possible choice because representation digest requires complete
	representation metadata (see <xref target="representation-digest"/>).</t>	representation metadata (see <xref target="representation-digest"/>).</t>
	<t>In responses,</t>	<t>In responses,</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>if the representation describes the status of the request,	<li>if the representation describes the status of the request,
	<tt>Repr-Digest</tt> <bcp14>MUST</bcp14> be computed on the enclosed representat ion	<tt>Repr-Digest</tt> <bcp14>MUST</bcp14> be computed on the enclosed representat ion
	(see <xref target="post-referencing-status"/>);</li>	(see <xref target="post-referencing-status"/>);</li>

	<li>if there is a referenced resource	<li>if there is a referenced resource, <tt>Repr-Digest</tt>
	<tt>Repr-Digest</tt> <bcp14>MUST</bcp14> be computed on the selected representat	<bcp14>MUST</bcp14> be computed on the selected representation of
	ion of the referenced resource	the referenced resource even if that is different from the target
	even if that is different from the target resource.	resource. This might or might not result in computing
	That might or might not result in computing <tt>Repr-Digest</tt> on the enclose	<tt>Repr-Digest</tt> on the enclosed representation.</li>
	d representation.</li>
	</ul>	</ul>
	<t>The latter case is done according to the HTTP semantics of the given	<t>The latter case is done according to the HTTP semantics of the given

	method, for example using the <tt>Content-Location</tt> header field (see <xref section="8.7" sectionFormat="of" target="RFC9110"/>).	method, for example, using the <tt>Content-Location</tt> header field (see <xref section="8.7" sectionFormat="of" target="RFC9110"/>).
	In contrast, the <tt>Location</tt> header field does not affect <tt>Repr-Digest< /tt> because	In contrast, the <tt>Location</tt> header field does not affect <tt>Repr-Digest< /tt> because
	it is not representation metadata.</t>	it is not representation metadata.</t>

	<t>For example, in <tt>PATCH</tt> requests, the representation digest	<t>For example, in PATCH requests, the representation digest
	will be computed on the patch document	will be computed on the patch document
	because the representation metadata refers to the patch document and not	because the representation metadata refers to the patch document and not

	to the target resource (see <xref section="2" sectionFormat="of" target="PATCH"/ >).	the target resource (see <xref section="2" sectionFormat="of" target="RFC5789"/> ).
	In responses, instead, the representation digest will be computed on the selecte d	In responses, instead, the representation digest will be computed on the selecte d
	representation of the patched resource.</t>	representation of the patched resource.</t>
	</section>	</section>
	<section anchor="digest-and-content-location">	<section anchor="digest-and-content-location">

	<name>Repr-Digest and Content-Location in Responses</name>	<name><tt>Repr-Digest</tt> and Content-Location in Responses</name>
	<t>When a state-changing method returns the <tt>Content-Location</tt> he ader field, the	<t>When a state-changing method returns the <tt>Content-Location</tt> he ader field, the
	enclosed representation refers to the resource identified by its value and	enclosed representation refers to the resource identified by its value and
	<tt>Repr-Digest</tt> is computed accordingly.	<tt>Repr-Digest</tt> is computed accordingly.
	An example is given in <xref target="post-not-request-uri"/>.</t>	An example is given in <xref target="post-not-request-uri"/>.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="want-fields">	<section anchor="want-fields">

	<name>Integrity preference fields</name>	<name>Integrity Preference Fields</name>
	<t>Senders can indicate their interest in Integrity fields and hashing alg orithm	<t>Senders can indicate their interest in Integrity fields and hashing alg orithm
	preferences using the	preferences using the

	<tt>Want-Content-Digest</tt> or <tt>Want-Repr-Digest</tt> fields. These can be u sed in both	<tt>Want-Content-Digest</tt> or <tt>Want-Repr-Digest</tt> HTTP fields. These can be used in both
	requests and responses.</t>	requests and responses.</t>

	<t><tt>Want-Content-Digest</tt> indicates that the sender would like to re
	ceive a content digest	<t><tt>Want-Content-Digest</tt> indicates that the sender would like to
	on messages associated with the request URI and representation metadata, using	receive (via the <tt>Content-Digest</tt> field) a content digest on messages
	the <tt>Content-Digest</tt> field.</t>	associated with the request URI and representation metadata.
	<t><tt>Want-Repr-Digest</tt> indicates that the sender would like to recei
	ve a representation digest	<tt>Want-Repr-Digest</tt> indicates that the sender would like to receive
	on messages associated with the request URI and representation metadata, using	(via the <tt>Repr-Digest</tt> field) a representation digest on messages
	the <tt>Repr-Digest</tt> field.</t>	associated with the request URI and representation metadata.
		</t>

	<t>If <tt>Want-Content-Digest</tt> or <tt>Want-Repr-Digest</tt> are used i n a response, it	<t>If <tt>Want-Content-Digest</tt> or <tt>Want-Repr-Digest</tt> are used i n a response, it
	indicates that the server would like the client to provide the respective	indicates that the server would like the client to provide the respective
	Integrity field on future requests.</t>	Integrity field on future requests.</t>
	<t>Integrity preference fields are only a hint. The receiver of the field can	<t>Integrity preference fields are only a hint. The receiver of the field can
	ignore it and send an Integrity field using any algorithm or omit the field	ignore it and send an Integrity field using any algorithm or omit the field

	entirely, for example see <xref target="ex-server-selects-unsupported-algorithm" />. It is not	entirely; for example, see <xref target="ex-server-selects-unsupported-algorithm "/>. It is not
	a protocol error if preferences are ignored. Applications that use Integrity	a protocol error if preferences are ignored. Applications that use Integrity
	fields and Integrity preferences can define expectations or constraints that	fields and Integrity preferences can define expectations or constraints that
	operate in addition to this specification. Ignored preferences are an	operate in addition to this specification. Ignored preferences are an
	application-specific concern.</t>	application-specific concern.</t>

	<t><tt>Want-Content-Digest</tt> and <tt>Want-Repr-Digest</tt> are of type <tt>Dictionary</tt>	<t><tt>Want-Content-Digest</tt> and <tt>Want-Repr-Digest</tt> are of type Dictionary
	where each:</t>	where each:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>key conveys the hashing algorithm (see <xref target="algorithms"/>); </li>	<li>key conveys the hashing algorithm (see <xref target="algorithms"/>); </li>

	<li>value is an <tt>Integer</tt> (<xref section="3.3.1" sectionFormat="o f" target="STRUCTURED-FIELDS"/>)	<li>value is an <tt>Integer</tt> (<xref section="3.3.1" sectionFormat="o f" target="RFC8941"/>)
	that conveys an ascending, relative, weighted preference.	that conveys an ascending, relative, weighted preference.
	It must be in the range 0 to 10 inclusive.	It must be in the range 0 to 10 inclusive.
	1 is the least preferred, 10 is the most preferred,	1 is the least preferred, 10 is the most preferred,
	and a value of 0 means "not acceptable".</li>	and a value of 0 means "not acceptable".</li>
	</ul>	</ul>
	<t>Examples:</t>	<t>Examples:</t>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	Want-Repr-Digest: sha-256=1	Want-Repr-Digest: sha-256=1
	Want-Repr-Digest: sha-512=3, sha-256=10, unixsum=0	Want-Repr-Digest: sha-512=3, sha-256=10, unixsum=0
	Want-Content-Digest: sha-256=1	Want-Content-Digest: sha-256=1

	skipping to change at line 405 ¶	skipping to change at line 387 ¶
	<section anchor="algorithms">	<section anchor="algorithms">
	<name>Hash Algorithm Considerations and Registration</name>	<name>Hash Algorithm Considerations and Registration</name>
	<t>There are a wide variety of hashing algorithms that can be used for the purposes	<t>There are a wide variety of hashing algorithms that can be used for the purposes
	of integrity. The choice of algorithm depends on several factors such as the	of integrity. The choice of algorithm depends on several factors such as the
	integrity use case, implementation needs or constraints, or application design	integrity use case, implementation needs or constraints, or application design
	and workflows.</t>	and workflows.</t>
	<t>An initial set of algorithms will be registered with IANA in the "Hash	<t>An initial set of algorithms will be registered with IANA in the "Hash
	Algorithms for HTTP Digest Fields" registry; see	Algorithms for HTTP Digest Fields" registry; see
	<xref target="establish-hash-algorithm-registry"/>. Additional algorithms can be registered	<xref target="establish-hash-algorithm-registry"/>. Additional algorithms can be registered
	in accordance with the policies set out in this section.</t>	in accordance with the policies set out in this section.</t>

	<t>Each algorithm has a status field, which is intended to provide an aid to	<t>Each algorithm has a status field that is intended to provide an aid to
	implementation selection.</t>	implementation selection.</t>
	<t>Algorithms with a status value of "Active" are suitable for many purpos es and	<t>Algorithms with a status value of "Active" are suitable for many purpos es and
	it is <bcp14>RECOMMENDED</bcp14> that applications use these algorithms. These c an be used in	it is <bcp14>RECOMMENDED</bcp14> that applications use these algorithms. These c an be used in
	adversarial situations where hash functions might need to provide resistance to	adversarial situations where hash functions might need to provide resistance to

	collision, first-preimage and second-preimage attacks. For adversarial	collision, first-preimage, and second-preimage attacks.
	situations, selecting which of the "Active" algorithms are acceptable will
	depend on the level of protection the circumstances demand.	For adversarial situations, selection of the acceptable "Active" algorithms
	More considerations are presented in <xref target="sec-agility"/>.</t>	will depend on the level of protection the circumstances demand. More
		considerations are presented in <xref target="sec-agility"/>.</t>
	<t>Algorithms with a status value of "Deprecated" either provide none of t hese	<t>Algorithms with a status value of "Deprecated" either provide none of t hese

	properties, or are known to be weak (see <xref target="NO-MD5"/> and <xref targe t="NO-SHA"/>). These	properties or are known to be weak (see <xref target="RFC6151"/> and <xref targe t="RFC6194"/>). These
	algorithms <bcp14>MAY</bcp14> be used to preserve integrity against corruption, but <bcp14>MUST NOT</bcp14> be	algorithms <bcp14>MAY</bcp14> be used to preserve integrity against corruption, but <bcp14>MUST NOT</bcp14> be

	used in a potentially adversarial setting; for example, when signing Integrity	used in a potentially adversarial setting, for example, when signing Integrity
	fields' values for authenticity. Permitting the use of these algorithms can help	fields' values for authenticity.
	some applications, for example, those that previously used <xref target="RFC3230
	"/>, are	Permitting the use of these algorithms can help some applications (such as
	migrating to this specification (<xref target="migrating"/>), and have existing	those that previously used <xref target="RFC3230"/>, are migrating to this sp
	stored	ecification
	collections of computed digest values avoid undue operational overhead caused by	(<xref target="migrating"/>), and have existing stored collections of compute
	recomputation using other more-secure algorithms. Such applications are not	d digest
		values) avoid undue operational overhead caused by recomputation using
		other more-secure algorithms.

		Such applications are not
	exempt from the requirements in this section. Furthermore, applications without	exempt from the requirements in this section. Furthermore, applications without
	such legacy or history ought to follow the guidance for using algorithms with	such legacy or history ought to follow the guidance for using algorithms with
	the status value "Active".</t>	the status value "Active".</t>
	<t>Discussion of algorithm agility is presented in <xref target="sec-agili ty"/>.</t>	<t>Discussion of algorithm agility is presented in <xref target="sec-agili ty"/>.</t>
	<t>Registration requests for the "Hash Algorithms for HTTP Digest Fields" registry	<t>Registration requests for the "Hash Algorithms for HTTP Digest Fields" registry
	use the Specification Required policy (<xref section="4.6" sectionFormat="of" ta rget="RFC8126"/>). Requests	use the Specification Required policy (<xref section="4.6" sectionFormat="of" ta rget="RFC8126"/>). Requests
	should use the following template:</t>	should use the following template:</t>

	<ul spacing="normal">	<dl>
	<li>Algorithm Key: the Structured Fields key value used in	<dt>Algorithm Key:</dt><dd>The Structured Fields key value used in
	<tt>Content-Digest</tt>, <tt>Repr-Digest</tt>, <tt>Want-Content-Digest</tt>, or <tt>Want-Repr-Digest</tt>	<tt>Content-Digest</tt>, <tt>Repr-Digest</tt>, <tt>Want-Content-Digest</tt>, or <tt>Want-Repr-Digest</tt>

	field Dictionary member keys</li>	field Dictionary member keys.</dd>
	<li>	<dt>Status:</dt><dd>The status of the algorithm. The options are:</dd>
	<t>Status: the status of the algorithm. The options are:	<dt></dt><dd>
	</t>	<dl spacing="normal">
	<ul spacing="normal">	<dt>"Active":</dt><dd>Algorithms without known problems</dd>
	<li>"Active" - for algorithms without known problems,</li>	<dt>"Provisional":</dt><dd>Unproven algorithms</dd>
	<li>"Provisional" - for unproven algorithms,</li>	<dt>"Deprecated":</dt><dd>Deprecated or insecure algorithms</dd>
	<li>"Deprecated" - for deprecated or insecure algorithms,</li>	</dl>
	</ul>	</dd>
	</li>	<dt>Description:</dt><dd>A short description of the algorithm.</dd>
	<li>Description: a short description of the algorithm</li>	<dt>Reference(s):</dt><dd>Pointer(s) to the primary document(s) defining
	<li>Reference(s): pointer(s) to the primary document(s) defining the Alg	the Algorithm
	orithm	Key and technical details of the algorithm.</dd>
	Key and technical details of the algorithm</li>	</dl>
	</ul>
	<t>When reviewing registration requests, the designated expert(s) should p ay	<t>When reviewing registration requests, the designated expert(s) should p ay
	attention to the requested status. The status value should reflect	attention to the requested status. The status value should reflect
	standardization status and the broad opinion of relevant interest groups such as	standardization status and the broad opinion of relevant interest groups such as

	the IETF or security-related SDOs. The "Active" status is not suitable for an	the IETF or security-related Standards Development Organizations (SDOs). The "Ac tive" status is not suitable for an
	algorithm that is known to be weak, broken, or experimental. If a registration	algorithm that is known to be weak, broken, or experimental. If a registration
	request attempts to register such an algorithm as "Active", the designated	request attempts to register such an algorithm as "Active", the designated
	expert(s) should suggest an alternative status of "Deprecated" or "Provisional". </t>	expert(s) should suggest an alternative status of "Deprecated" or "Provisional". </t>
	<t>When reviewing registration requests, the designated expert(s) cannot u se a	<t>When reviewing registration requests, the designated expert(s) cannot u se a
	status of "Deprecated" or "Provisional" as grounds for rejection.</t>	status of "Deprecated" or "Provisional" as grounds for rejection.</t>
	<t>Requests to update or change the fields in an existing registration are	<t>Requests to update or change the fields in an existing registration are
	permitted. For example, this could allow for the transition of an algorithm	permitted. For example, this could allow for the transition of an algorithm
	status from "Active" to "Deprecated" as the security environment evolves.</t>	status from "Active" to "Deprecated" as the security environment evolves.</t>
	</section>	</section>
	<section anchor="security">	<section anchor="security">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<section anchor="sec-limitations">	<section anchor="sec-limitations">

	<name>HTTP Messages Are Not Protected In Full</name>	<name>HTTP Messages Are Not Protected in Full</name>
	<t>This document specifies a data integrity mechanism that protects HTTP	<t>This document specifies a data integrity mechanism that protects HTTP
	representation data or content, but not HTTP header and trailer fields, from	representation data or content, but not HTTP header and trailer fields, from
	certain kinds of corruption.</t>	certain kinds of corruption.</t>
	<t>Integrity fields are not intended to be a general protection against malicious tampering with	<t>Integrity fields are not intended to be a general protection against malicious tampering with
	HTTP messages.	HTTP messages.

	In the absence of additional security mechanisms,	In the absence of additional
	an on-path, malicious actor can remove or recalculate and substitute a digest	security mechanisms, an on-path malicious actor can either remove
	value.	a digest value entirely or substitute it with a new digest value computed over
		manipulated representation data or content.
	This attack can be mitigated by combining mechanisms described in this	This attack can be mitigated by combining mechanisms described in this
	document with other approaches such	document with other approaches such

	as transport-layer security or digital signatures (for example, HTTP Message	as Transport Layer Security (TLS) or digital signatures (for example, HTTP Messa
	Signatures <xref target="SIGNATURES"/>).</t>	ge
		Signatures <xref target="RFC9421"/>).</t>
	</section>	</section>
	<section anchor="end-to-end-integrity">	<section anchor="end-to-end-integrity">
	<name>End-to-End Integrity</name>	<name>End-to-End Integrity</name>
	<t>Integrity fields can help detect representation data or content modif ication due to implementation errors,	<t>Integrity fields can help detect representation data or content modif ication due to implementation errors,

	undesired "transforming proxies" (see <xref section="7.7" sectionFormat="of" tar get="RFC9110"/>)	undesired "transforming proxies" (see <xref section="7.7" sectionFormat="of" tar get="RFC9110"/>),
	or other actions as the data passes across multiple hops or system boundaries.	or other actions as the data passes across multiple hops or system boundaries.
	Even a simple mechanism for end-to-end representation data integrity is valuable	Even a simple mechanism for end-to-end representation data integrity is valuable
	because a user agent can validate that resource retrieval succeeded before handi ng off to an	because a user agent can validate that resource retrieval succeeded before handi ng off to an

	HTML parser, video player, etc. for parsing.</t>	HTML parser, video player, etc., for parsing.</t>
	<t>Note that using these mechanisms alone does not provide end-to-end in tegrity of HTTP messages over	<t>Note that using these mechanisms alone does not provide end-to-end in tegrity of HTTP messages over

	multiple hops, since metadata could be manipulated at any stage. Methods to prot ect	multiple hops since metadata could be manipulated at any stage. Methods to prote ct
	metadata are discussed in <xref target="usage-in-signatures"/>.</t>	metadata are discussed in <xref target="usage-in-signatures"/>.</t>
	</section>	</section>
	<section anchor="usage-in-signatures">	<section anchor="usage-in-signatures">
	<name>Usage in Signatures</name>	<name>Usage in Signatures</name>
	<t>Digital signatures are widely used together with checksums to provide the	<t>Digital signatures are widely used together with checksums to provide the

	certain identification of the origin of a message <xref target="NIST800-32"/>. S uch signatures	certain identification of the origin of a message <xref target="FIPS186-5"/>. Su ch signatures
	can protect one or more HTTP fields and there are additional considerations when	can protect one or more HTTP fields and there are additional considerations when
	Integrity fields are included in this set.</t>	Integrity fields are included in this set.</t>
	<t>There are no restrictions placed on the type or format of digital sig nature that	<t>There are no restrictions placed on the type or format of digital sig nature that
	Integrity fields can be used with. One possible approach is to combine them with	Integrity fields can be used with. One possible approach is to combine them with

	HTTP Message Signatures <xref target="SIGNATURES"/>.</t>	HTTP Message Signatures <xref target="RFC9421"/>.</t>
	<t>Digests explicitly	<t>Digests explicitly
	depend on the "representation metadata" (e.g., the values of <tt>Content-Type</t t>,	depend on the "representation metadata" (e.g., the values of <tt>Content-Type</t t>,

	<tt>Content-Encoding</tt> etc.). A signature that protects Integrity fields but not other	<tt>Content-Encoding</tt>, etc.). A signature that protects Integrity fields but not other
	"representation metadata" can expose the communication to tampering. For	"representation metadata" can expose the communication to tampering. For
	example, an actor could manipulate the <tt>Content-Type</tt> field-value and cau se a	example, an actor could manipulate the <tt>Content-Type</tt> field-value and cau se a
	digest validation failure at the recipient, preventing the application from	digest validation failure at the recipient, preventing the application from
	accessing the representation. Such an attack consumes the resources of both	accessing the representation. Such an attack consumes the resources of both
	endpoints. See also <xref target="digest-and-content-location"/>.</t>	endpoints. See also <xref target="digest-and-content-location"/>.</t>


	<t>Signatures are likely to be deemed an adversarial setting when applyi ng	<t>Signatures are likely to be deemed an adversarial setting when applyi ng
	Integrity fields; see <xref target="algorithms"/>. <tt>Repr-Digest</tt> offers a n interesting	Integrity fields; see <xref target="algorithms"/>. <tt>Repr-Digest</tt> offers a n interesting
	possibility when combined with signatures. In the scenario where there is no	possibility when combined with signatures. In the scenario where there is no
	content to send, the digest of an empty string can be included in the message	content to send, the digest of an empty string can be included in the message

	and, if signed, can help the recipient detect if content was added either as a	and, if signed, can help the recipient detect if content was added either as a r
	result of accident or purposeful manipulation. The opposite scenario is also	esult of accident or purposeful manipulation. The opposite scenario is also
	supported; including an Integrity field for content, and signing it, can help a	supported; including an Integrity field for content and signing it can help a
	recipient detect where the content was removed.</t>	recipient detect where the content was removed.</t>

	<t>Any mangling of Integrity fields, including digests' de-duplication	<t>Any mangling of Integrity fields might affect signature validation. Examples
	or combining different field values (see <xref section="5.2" sectionFormat="of"	of such mangling include de-duplicating digests or combining different field val
	target="RFC9110"/>)	ues (see <xref section="5.2" sectionFormat="of" target="RFC9110"/>).</t>
	might affect signature validation.</t>
	</section>	</section>
	<section anchor="usage-in-trailer-fields">	<section anchor="usage-in-trailer-fields">
	<name>Usage in Trailer Fields</name>	<name>Usage in Trailer Fields</name>
	<t>Before sending Integrity fields in a trailer section, the sender	<t>Before sending Integrity fields in a trailer section, the sender
	should consider that intermediaries are explicitly allowed to drop any trailer	should consider that intermediaries are explicitly allowed to drop any trailer
	(see <xref section="6.5.2" sectionFormat="of" target="RFC9110"/>).</t>	(see <xref section="6.5.2" sectionFormat="of" target="RFC9110"/>).</t>
	<t>When Integrity fields are used in a trailer section, the field-values are received after the content.	<t>When Integrity fields are used in a trailer section, the field-values are received after the content.
	Eager processing of content before the trailer section prevents digest validatio n, possibly leading to	Eager processing of content before the trailer section prevents digest validatio n, possibly leading to
	processing of invalid data.</t>	processing of invalid data.</t>
	<t>One of the benefits of using Integrity fields in a trailer section is that it	<t>One of the benefits of using Integrity fields in a trailer section is that it
	allows hashing of bytes as they are sent. However, it is possible to	allows hashing of bytes as they are sent. However, it is possible to
	design a hashing algorithm that requires processing of content in such a way	design a hashing algorithm that requires processing of content in such a way
	that would negate these benefits. For example, Merkle Integrity Content Encoding	that would negate these benefits. For example, Merkle Integrity Content Encoding
	<xref target="I-D.thomson-http-mice"/> requires content to be processed in rever se order.	<xref target="I-D.thomson-http-mice"/> requires content to be processed in rever se order.
	This means the complete data needs to be available, which means there is	This means the complete data needs to be available, which means there is

	negligible processing difference in sending an Integrity field in a header or	negligible processing difference in sending an Integrity field in a header versu
	trailer section.</t>	s
		a trailer section.</t>
	</section>	</section>
	<section anchor="variations-within-content-encoding">	<section anchor="variations-within-content-encoding">

	<name>Variations Within Content Encoding</name>	<name>Variations within Content-Encoding</name>
	<t>Content coding mechanisms can support different encoding parameters, meaning that the same input content can produce different outputs. For example, GZIP supports multiple compression levels. Such encoding parameters are generall y not communicated as representation metadata. For instance, different compressi on levels would all use the same "Content-Encoding: gzip" field. Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm con tent coding defined in <xref target="RFC8188"/>.</t>	<t>Content coding mechanisms can support different encoding parameters, meaning that the same input content can produce different outputs. For example, GZIP supports multiple compression levels. Such encoding parameters are generall y not communicated as representation metadata. For instance, different compressi on levels would all use the same "Content-Encoding: gzip" field. Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm con tent coding defined in <xref target="RFC8188"/>.</t>

	<t>Since it is possible for there to be variation within content coding, the checksum conveyed by the integrity fields cannot be used to provide a proof of integrity "at rest"	<t>Since it is possible for there to be variation within content coding, the checksum conveyed by the Integrity fields cannot be used to provide a proof of integrity "at rest"
	unless the whole content is persisted.</t>	unless the whole content is persisted.</t>
	</section>	</section>
	<section anchor="sec-agility">	<section anchor="sec-agility">
	<name>Algorithm Agility</name>	<name>Algorithm Agility</name>
	<t>The security properties of hashing algorithms are not fixed.	<t>The security properties of hashing algorithms are not fixed.

	Algorithm Agility (see <xref target="RFC7696"/>) is achieved by providing implem entations with flexibility	Algorithm agility (see <xref target="RFC7696"/>) is achieved by providing implem entations with flexibility
	to choose hashing algorithms from the IANA Hash Algorithms for HTTP Digest Field s registry; see	to choose hashing algorithms from the IANA Hash Algorithms for HTTP Digest Field s registry; see
	<xref target="establish-hash-algorithm-registry"/>.</t>	<xref target="establish-hash-algorithm-registry"/>.</t>
	<t>Transition from weak algorithms is supported	<t>Transition from weak algorithms is supported
	by negotiation of hashing algorithm using <tt>Want-Content-Digest</tt> or <tt>Wa nt-Repr-Digest</tt> (see <xref target="want-fields"/>)	by negotiation of hashing algorithm using <tt>Want-Content-Digest</tt> or <tt>Wa nt-Repr-Digest</tt> (see <xref target="want-fields"/>)
	or by sending multiple digests from which the receiver chooses.	or by sending multiple digests from which the receiver chooses.
	A receiver that depends on a digest for security will be vulnerable	A receiver that depends on a digest for security will be vulnerable
	to attacks on the weakest algorithm it is willing to accept.	to attacks on the weakest algorithm it is willing to accept.

	Endpoints are advised that sending multiple values consumes resources,	Endpoints are advised that sending multiple values consumes resources that may b
	which may be wasted if the receiver ignores them (see <xref target="representati	e wasted if the receiver ignores them (see <xref target="representation-digest"/
	on-digest"/>).</t>	>).</t>
	<t>While algorithm agility allows the migration to stronger algorithms	<t>While algorithm agility allows the migration to stronger algorithms,
	it does not prevent the use of weaker algorithms.	it does not prevent the use of weaker algorithms.
	Integrity fields do not provide any mitigations for downgrade or substitution	Integrity fields do not provide any mitigations for downgrade or substitution

	attacks (see Section 1 of <xref target="RFC6211"/>) of the hashing algorithm.	attacks (see <xref target="RFC6211" sectionFormat="of" section="1"/>) of the has hing algorithm.
	To protect against such attacks, endpoints could restrict their set of supported algorithms	To protect against such attacks, endpoints could restrict their set of supported algorithms

	to stronger ones and protect the fields value by using TLS and/or digital signat ures.</t>	to stronger ones and protect the fields' values by using TLS and/or digital sign atures.</t>
	</section>	</section>
	<section anchor="sec-exhaustion">	<section anchor="sec-exhaustion">

	<name>Resource exhaustion</name>	<name>Resource Exhaustion</name>
	<t>Integrity fields validation consumes computational resources.	<t>Integrity field validation consumes computational resources.
	In order to avoid resource exhaustion, implementations can restrict	In order to avoid resource exhaustion, implementations can restrict

	validation of the algorithm types, number of validations, or the size of content .	validation of the algorithm types, the number of validations, or the size of con tent.
	In these cases, skipping validation entirely or ignoring validation failure of a more-preferred algorithm	In these cases, skipping validation entirely or ignoring validation failure of a more-preferred algorithm
	leaves the possibility of a downgrade attack (see <xref target="sec-agility"/>). </t>	leaves the possibility of a downgrade attack (see <xref target="sec-agility"/>). </t>
	</section>	</section>
	</section>	</section>
	<section anchor="iana-considerations">	<section anchor="iana-considerations">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>
	<section anchor="http-field-name-registration">	<section anchor="http-field-name-registration">
	<name>HTTP Field Name Registration</name>	<name>HTTP Field Name Registration</name>

	<t>IANA is asked to update the	<t>IANA has updated the
	"Hypertext Transfer Protocol (HTTP) Field Name Registry" registry	"Hypertext Transfer Protocol (HTTP) Field Name Registry"
	(<xref target="RFC9110"/>) according to the table below:</t>	<xref target="RFC9110"/> as shown in the table below:</t>
	<table>	<table>

		<name>Hypertext Transfer Protocol (HTTP) Field
		Name Registry Update</name>
	<thead>	<thead>
	<tr>	<tr>
	<th align="left">Field Name</th>	<th align="left">Field Name</th>
	<th align="left">Status</th>	<th align="left">Status</th>
	<th align="left">Reference</th>	<th align="left">Reference</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>

	<td align="left">Content-Digest</td>	<td align="left"><tt>Content-Digest</tt></td>
	<td align="left">permanent</td>	<td align="left">permanent</td>
	<td align="left">	<td align="left">

	<xref target="content-digest"/> of this document</td>	<xref target="content-digest"/> of RFC 9530</td>
	</tr>	</tr>
	<tr>	<tr>

	<td align="left">Repr-Digest</td>	<td align="left"><tt>Repr-Digest</tt></td>
	<td align="left">permanent</td>	<td align="left">permanent</td>
	<td align="left">	<td align="left">

	<xref target="representation-digest"/> of this document</td>	<xref target="representation-digest"/> of RFC 9530</td>
	</tr>	</tr>
	<tr>	<tr>

	<td align="left">Want-Content-Digest</td>	<td align="left"><tt>Want-Content-Digest</tt></td>
	<td align="left">permanent</td>	<td align="left">permanent</td>
	<td align="left">	<td align="left">

	<xref target="want-fields"/> of this document</td>	<xref target="want-fields"/> of RFC 9530</td>
	</tr>	</tr>
	<tr>	<tr>

	<td align="left">Want-Repr-Digest</td>	<td align="left"><tt>Want-Repr-Digest</tt></td>
	<td align="left">permanent</td>	<td align="left">permanent</td>
	<td align="left">	<td align="left">

	<xref target="want-fields"/> of this document</td>	<xref target="want-fields"/> of RFC 9530</td>
	</tr>	</tr>
	<tr>	<tr>

	<td align="left">Digest</td>	<td align="left"><tt>Digest</tt></td>
	<td align="left">obsoleted</td>	<td align="left">obsoleted</td>
	<td align="left">	<td align="left">

	<xref target="RFC3230"/>, <xref target="obsolete-3230"/> of this document</td>	<xref target="RFC3230"/>, <xref target="obsolete-3230"/> of RFC 9530</td>
	</tr>	</tr>
	<tr>	<tr>

	<td align="left">Want-Digest</td>	<td align="left"><tt>Want-Digest</tt></td>
	<td align="left">obsoleted</td>	<td align="left">obsoleted</td>
	<td align="left">	<td align="left">

	<xref target="RFC3230"/>, <xref target="obsolete-3230"/> of this document</td>	<xref target="RFC3230"/>, <xref target="obsolete-3230"/> of RFC 9530</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>
	<section anchor="establish-hash-algorithm-registry">	<section anchor="establish-hash-algorithm-registry">

	<name>Establish the Hash Algorithms for HTTP Digest Fields Registry</nam	<name>Creation of the Hash Algorithms for HTTP Digest Fields Registry</n
	e>	ame>
	<t>IANA is requested to create the new "Hash Algorithms for HTTP Digest	<t>IANA has created the new "Hash Algorithms for HTTP Digest Fields"
	Fields"	registry at <eref brackets="angle" target="https://www.iana.org/assignments/http
	registry at <eref target="https://www.iana.org/assignments/http-digest-hash-alg/	-digest-hash-alg/"/> and
	">https://www.iana.org/assignments/http-digest-hash-alg/</eref> and	populated it with the entries in <xref target="iana-hash-algorithm-table"/>. The
	populate it with the entries in <xref target="iana-hash-algorithm-table"/>. The	procedure for
	procedure for
	new registrations is provided in <xref target="algorithms"/>.</t>	new registrations is provided in <xref target="algorithms"/>.</t>
	<table anchor="iana-hash-algorithm-table">	<table anchor="iana-hash-algorithm-table">
	<name>Initial Hash Algorithms</name>	<name>Initial Hash Algorithms</name>
	<thead>	<thead>
	<tr>	<tr>
	<th align="left">Algorithm Key</th>	<th align="left">Algorithm Key</th>
	<th align="left">Status</th>	<th align="left">Status</th>
	<th align="left">Description</th>	<th align="left">Description</th>

	<th align="left">Reference(s)</th>	<th align="left">Reference</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td align="left">sha-512</td>	<td align="left">sha-512</td>
	<td align="left">Active</td>	<td align="left">Active</td>
	<td align="left">The SHA-512 algorithm.</td>	<td align="left">The SHA-512 algorithm.</td>
	<td align="left">	<td align="left">

	<xref target="RFC6234"/>, <xref target="RFC4648"/>, this documen t.</td>	<xref target="RFC6234"/>, <xref target="RFC4648"/>, RFC 9530</td >
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">sha-256</td>	<td align="left">sha-256</td>
	<td align="left">Active</td>	<td align="left">Active</td>
	<td align="left">The SHA-256 algorithm.</td>	<td align="left">The SHA-256 algorithm.</td>
	<td align="left">	<td align="left">

	<xref target="RFC6234"/>, <xref target="RFC4648"/>, this documen t.</td>	<xref target="RFC6234"/>, <xref target="RFC4648"/>, RFC 9530</td >
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">md5</td>	<td align="left">md5</td>
	<td align="left">Deprecated</td>	<td align="left">Deprecated</td>

	<td align="left">The MD5 algorithm. It is vulnerable to collision attacks; see <xref target="NO-MD5"/> and <xref target="CMU-836068"/></td>	<td align="left">The MD5 algorithm. It is vulnerable to collision attacks; see <xref target="RFC6151"/> and <xref target="CMU-836068"/></td>
	<td align="left">	<td align="left">

	<xref target="RFC1321"/>, <xref target="RFC4648"/>, this documen t.</td>	<xref target="RFC1321"/>, <xref target="RFC4648"/>, RFC 9530</td >
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">sha</td>	<td align="left">sha</td>
	<td align="left">Deprecated</td>	<td align="left">Deprecated</td>

	<td align="left">The SHA-1 algorithm. It is vulnerable to collisio n attacks; see <xref target="NO-SHA"/> and <xref target="IACR-2020-014"/></td>	<td align="left">The SHA-1 algorithm. It is vulnerable to collisio n attacks; see <xref target="RFC6194"/> and <xref target="IACR-2020-014"/></td>
	<td align="left">	<td align="left">

	<xref target="RFC3174"/>, <xref target="RFC4648"/>, <xref target ="RFC6234"/> this document.</td>	<xref target="RFC3174"/>, <xref target="RFC4648"/>, <xref target ="RFC6234"/>, RFC 9530</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">unixsum</td>	<td align="left">unixsum</td>
	<td align="left">Deprecated</td>	<td align="left">Deprecated</td>
	<td align="left">The algorithm used by the UNIX "sum" command.</td >	<td align="left">The algorithm used by the UNIX "sum" command.</td >
	<td align="left">	<td align="left">

	<xref target="RFC4648"/>, <xref target="RFC6234"/>, <xref target ="UNIX"/>, this document.</td>	<xref target="RFC4648"/>, <xref target="RFC6234"/>, <xref target ="UNIX"/>, RFC 9530</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">unixcksum</td>	<td align="left">unixcksum</td>
	<td align="left">Deprecated</td>	<td align="left">Deprecated</td>
	<td align="left">The algorithm used by the UNIX "cksum" command.</ td>	<td align="left">The algorithm used by the UNIX "cksum" command.</ td>
	<td align="left">	<td align="left">

	<xref target="RFC4648"/>, <xref target="RFC6234"/>, <xref target ="UNIX"/>, this document.</td>	<xref target="RFC4648"/>, <xref target="RFC6234"/>, <xref target ="UNIX"/>, RFC 9530</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">adler</td>	<td align="left">adler</td>
	<td align="left">Deprecated</td>	<td align="left">Deprecated</td>
	<td align="left">The ADLER32 algorithm.</td>	<td align="left">The ADLER32 algorithm.</td>
	<td align="left">	<td align="left">

	<xref target="RFC1950"/>, this document.</td>	<xref target="RFC1950"/>, RFC 9530</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">crc32c</td>	<td align="left">crc32c</td>
	<td align="left">Deprecated</td>	<td align="left">Deprecated</td>
	<td align="left">The CRC32c algorithm.</td>	<td align="left">The CRC32c algorithm.</td>

	<td align="left">	<td align="left"><xref target="RFC9260" sectionFormat="of" section
	<xref target="RFC9260"/> appendix A, this document.</td>	="A"/>, RFC 9530</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>
	<section anchor="deprecate-the-hypertext-transfer-protocol-http-digest-alg orithm-values-registry">	<section anchor="deprecate-the-hypertext-transfer-protocol-http-digest-alg orithm-values-registry">
	<name>Deprecate the Hypertext Transfer Protocol (HTTP) Digest Algorithm Values Registry</name>	<name>Deprecate the Hypertext Transfer Protocol (HTTP) Digest Algorithm Values Registry</name>

	<t>IANA is requested to deprecate the "Hypertext Transfer Protocol (HTTP ) Digest	<t>IANA has deprecated the "Hypertext Transfer Protocol (HTTP) Digest
	Algorithm Values" registry at	Algorithm Values" registry at

	<eref target="https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml">	<eref brackets="angle" target="https://www.iana.org/assignments/http-dig-alg/"/>
	https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml</eref> and repl	and replaced the note on that registry with the following text:</t>
	ace the note on this registry with the following text:</t>	<blockquote>This registry is deprecated since it lists the algorithm
	<ul empty="true">	s that can be used
	<li>	with the <tt>Digest</tt> and <tt>Want-Digest</tt> fields defined in <xref target
	<t>"This registry is deprecated since it lists the algorithms that c	="RFC3230"/>, which has been obsoleted by
	an be used	RFC 9530. While registration is not closed, new registrations
	with the Digest and Want-Digest fields defined in	are encouraged to use the <eref target="https://www.iana.org/assignments/http-di
	<xref target="RFC3230"/><eref target="https://www.iana.org/">https://www.iana.or	gest-hash-alg/">Hash Algorithms for HTTP Digest
	g/</eref>, which has been obsoleted by	Fields</eref> registry instead.</blockquote>
	[rfc-to-be-this-document]. While registration is not closed, new registrations
	are encouraged to use the [Hash Algorithms for HTTP Digest
	Fields]<eref target="https://www.iana.org/assignments/http-digest-hash-alg/">htt
	ps://www.iana.org/assignments/http-digest-hash-alg/</eref> registry
	instead.</t>
	</li>
	</ul>
	</section>	</section>
	</section>	</section>
	</middle>	</middle>
	<back>	<back>


	<displayreference target="RFC9110" to="HTTP"/>	<displayreference target="RFC9110" to="HTTP"/>
	<displayreference target="RFC9112" to="HTTP/1.1"/>	<displayreference target="RFC9112" to="HTTP/1.1"/>

		<displayreference target="RFC8792" to="FOLDING"/>
		<displayreference target="RFC8941" to="STRUCTURED-FIELDS"/>
		<displayreference target="RFC5789" to="PATCH"/>
		<displayreference target="RFC6151" to="NO-MD5"/>
		<displayreference target="RFC6194" to="NO-SHA"/>
		<displayreference target="RFC9421" to="SIGNATURES"/>
		<displayreference target="RFC8446" to="TLS"/>
		<displayreference target="I-D.thomson-http-mice" to="MICE"/>

	<references>	<references>
	<name>References</name>	<name>References</name>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>

	<reference anchor="RFC1321">
	<front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml"
	<title>The MD5 Message-Digest Algorithm</title>	/>
	<author fullname="R. Rivest" initials="R." surname="Rivest"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3174.xml"
	<date month="April" year="1992"/>	/>
	<abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1950.xml"
	<t>This document describes the MD5 message-digest algorithm. The a	/>
	lgorithm takes as input a message of arbitrary length and produces as output a 1	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"
	28-bit "fingerprint" or "message digest" of the input. This memo provides inform	/>
	ation for the Internet community. It does not specify an Internet standard.</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
	</abstract>	/>
	</front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"
	<seriesInfo name="RFC" value="1321"/>	/>
	<seriesInfo name="DOI" value="10.17487/RFC1321"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"
	</reference>	/>
	<reference anchor="RFC3174">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"
	<front>	/>
	<title>US Secure Hash Algorithm 1 (SHA1)</title>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"
	<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3	/>
	rd"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
	<author fullname="P. Jones" initials="P." surname="Jones"/>	/>
	<date month="September" year="2001"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
	<abstract>	/>
	<t>The purpose of this document is to make the SHA-1 (Secure Hash	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8941.xml"
	Algorithm 1) hash algorithm conveniently available to the Internet community. Th	/>
	is memo provides information for the Internet community.</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
	</abstract>	/>
	</front>
	<seriesInfo name="RFC" value="3174"/>
	<seriesInfo name="DOI" value="10.17487/RFC3174"/>
	</reference>
	<reference anchor="RFC1950">
	<front>
	<title>ZLIB Compressed Data Format Specification version 3.3</title>
	<author fullname="P. Deutsch" initials="P." surname="Deutsch"/>
	<author fullname="J-L. Gailly" surname="J-L. Gailly"/>
	<date month="May" year="1996"/>
	<abstract>
	<t>This specification defines a lossless compressed data format. T
	his memo provides information for the Internet community. This memo does not spe
	cify an Internet standard of any kind.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="1950"/>
	<seriesInfo name="DOI" value="10.17487/RFC1950"/>
	</reference>
	<reference anchor="RFC4648">
	<front>
	<title>The Base16, Base32, and Base64 Data Encodings</title>
	<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
	<date month="October" year="2006"/>
	<abstract>
	<t>This document describes the commonly used base 64, base 32, and
	base 16 encoding schemes. It also discusses the use of line-feeds in encoded da
	ta, use of padding in encoded data, use of non-alphabet characters in encoded da
	ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA
	CK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4648"/>
	<seriesInfo name="DOI" value="10.17487/RFC4648"/>
	</reference>
	<reference anchor="RFC5234">
	<front>
	<title>Augmented BNF for Syntax Specifications: ABNF</title>
	<author fullname="D. Crocker" initials="D." role="editor" surname="C
	rocker"/>
	<author fullname="P. Overell" initials="P." surname="Overell"/>
	<date month="January" year="2008"/>
	<abstract>
	<t>Internet technical specifications often need to define a formal
	syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Au
	gmented BNF (ABNF), has been popular among many Internet specifications. The cur
	rent specification documents ABNF. It balances compactness and simplicity with r
	easonable representational power. The differences between standard BNF and ABNF
	involve naming rules, repetition, alternatives, order-independence, and value ra
	nges. This specification also supplies additional rule definitions and encoding
	for a core lexical analyzer of the type common to several Internet specification
	s. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="68"/>
	<seriesInfo name="RFC" value="5234"/>
	<seriesInfo name="DOI" value="10.17487/RFC5234"/>
	</reference>
	<reference anchor="RFC6234">
	<front>
	<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</
	title>
	<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
	rd"/>
	<author fullname="T. Hansen" initials="T." surname="Hansen"/>
	<date month="May" year="2011"/>
	<abstract>
	<t>Federal Information Processing Standard, FIPS</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6234"/>
	<seriesInfo name="DOI" value="10.17487/RFC6234"/>
	</reference>
	<reference anchor="RFC7405">
	<front>
	<title>Case-Sensitive String Support in ABNF</title>
	<author fullname="P. Kyzivat" initials="P." surname="Kyzivat"/>
	<date month="December" year="2014"/>
	<abstract>
	<t>This document extends the base definition of ABNF (Augmented Ba
	ckus-Naur Form) to include a way to specify US-ASCII string literals that are ma
	tched in a case-sensitive manner.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7405"/>
	<seriesInfo name="DOI" value="10.17487/RFC7405"/>
	</reference>
	<reference anchor="FOLDING">
	<front>
	<title>Handling Long Lines in Content of Internet-Drafts and RFCs</t
	itle>
	<author fullname="K. Watsen" initials="K." surname="Watsen"/>
	<author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
	<author fullname="A. Farrel" initials="A." surname="Farrel"/>
	<author fullname="Q. Wu" initials="Q." surname="Wu"/>
	<date month="June" year="2020"/>
	<abstract>
	<t>This document defines two strategies for handling long lines in
	width-bounded text content. One strategy, called the "single backslash" strateg
	y, is based on the historical use of a single backslash ('\') character to indic
	ate where line-folding has occurred, with the continuation occurring with the fi
	rst character that is not a space character (' ') on the next line. The second s
	trategy, called the "double backslash" strategy, extends the first strategy by a
	dding a second backslash character to identify where the continuation begins and
	is thereby able to handle cases not supported by the first strategy. Both strat
	egies use a self-describing header enabling automated reconstitution of the orig
	inal content.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8792"/>
	<seriesInfo name="DOI" value="10.17487/RFC8792"/>
	</reference>
	<reference anchor="RFC9110">
	<front>
	<title>HTTP Semantics</title>
	<author fullname="R. Fielding" initials="R." role="editor" surname="
	Fielding"/>
	<author fullname="M. Nottingham" initials="M." role="editor" surname
	="Nottingham"/>
	<author fullname="J. Reschke" initials="J." role="editor" surname="R
	eschke"/>
	<date month="June" year="2022"/>
	<abstract>
	<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
	on-level protocol for distributed, collaborative, hypertext information systems.
	This document describes the overall architecture of HTTP, establishes common te
	rminology, and defines aspects of the protocol that are shared by all versions.
	In this definition are core protocol elements, extensibility mechanisms, and the
	"http" and "https" Uniform Resource Identifier (URI) schemes.</t>
	<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
	232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="97"/>
	<seriesInfo name="RFC" value="9110"/>
	<seriesInfo name="DOI" value="10.17487/RFC9110"/>
	</reference>
	<reference anchor="RFC2119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	le>
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized. T
	his document defines these words as they should be interpreted in IETF documents
	. This document specifies an Internet Best Current Practices for the Internet Co
	mmunity, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying that
	only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	<reference anchor="STRUCTURED-FIELDS">
	<front>
	<title>Structured Field Values for HTTP</title>
	<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
	>
	<author fullname="P-H. Kamp" surname="P-H. Kamp"/>
	<date month="February" year="2021"/>
	<abstract>
	<t>This document describes a set of data types and associated algo
	rithms that are intended to make it easier and safer to define and handle HTTP h
	eader and trailer fields, known as "Structured Fields", "Structured Headers", or
	"Structured Trailers". It is intended for use by specifications of new HTTP fie
	lds that wish to use a common syntax that is more restrictive than traditional H
	TTP field values.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8941"/>
	<seriesInfo name="DOI" value="10.17487/RFC8941"/>
	</reference>
	<reference anchor="RFC8126">
	<front>
	<title>Guidelines for Writing an IANA Considerations Section in RFCs
	</title>
	<author fullname="M. Cotton" initials="M." surname="Cotton"/>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<author fullname="T. Narten" initials="T." surname="Narten"/>
	<date month="June" year="2017"/>
	<abstract>
	<t>Many protocols make use of points of extensibility that use con
	stants to identify various protocol parameters. To ensure that the values in the
	se fields do not have conflicting uses and to promote interoperability, their al
	locations are often coordinated by a central record keeper. For IETF protocols,
	that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
	<t>To make assignments in a given registry prudently, guidance des
	cribing the conditions under which new values should be assigned, as well as whe
	n and how modifications to existing values can be made, is needed. This document
	defines a framework for the documentation of these guidelines by specification
	authors, in order to assure that the provided guidance for the IANA Consideratio
	ns is clear and addresses the various issues that are likely in the operation of
	a registry.</t>
	<t>This is the third edition of this document; it obsoletes RFC 52
	26.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="26"/>
	<seriesInfo name="RFC" value="8126"/>
	<seriesInfo name="DOI" value="10.17487/RFC8126"/>
	</reference>
	</references>	</references>
	<references>	<references>


	<name>Informative References</name>	<name>Informative References</name>

	<reference anchor="RFC3230">
	<front>
	<title>Instance Digests in HTTP</title>
	<author fullname="J. Mogul" initials="J." surname="Mogul"/>
	<author fullname="A. Van Hoff" initials="A." surname="Van Hoff"/>
	<date month="January" year="2002"/>
	<abstract>
	<t>HTTP/1.1 defines a Content-MD5 header that allows a server to i
	nclude a digest of the response body. However, this is specifically defined to c
	over the body of the actual message, not the contents of the full file (which mi
	ght be quite different, if the response is a Content-Range, or uses a delta enco
	ding). Also, the Content-MD5 is limited to one specific digest algorithm; other
	algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in som
	e circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a cli
	ent may request a digest. This document proposes HTTP extensions that solve thes
	e problems. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="3230"/>
	<seriesInfo name="DOI" value="10.17487/RFC3230"/>
	</reference>
	<reference anchor="RFC9112">
	<front>
	<title>HTTP/1.1</title>
	<author fullname="R. Fielding" initials="R." role="editor" surname="
	Fielding"/>
	<author fullname="M. Nottingham" initials="M." role="editor" surname
	="Nottingham"/>
	<author fullname="J. Reschke" initials="J." role="editor" surname="R
	eschke"/>
	<date month="June" year="2022"/>
	<abstract>
	<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
	on-level protocol for distributed, collaborative, hypertext information systems.
	This document specifies the HTTP/1.1 message syntax, message parsing, connectio
	n management, and related security concerns.</t>
	<t>This document obsoletes portions of RFC 7230.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="99"/>
	<seriesInfo name="RFC" value="9112"/>
	<seriesInfo name="DOI" value="10.17487/RFC9112"/>
	</reference>
	<reference anchor="PATCH">
	<front>
	<title>PATCH Method for HTTP</title>
	<author fullname="L. Dusseault" initials="L." surname="Dusseault"/>
	<author fullname="J. Snell" initials="J." surname="Snell"/>
	<date month="March" year="2010"/>
	<abstract>
	<t>Several applications extending the Hypertext Transfer Protocol
	(HTTP) require a feature to do partial resource modification. The existing HTTP
	PUT method only allows a complete replacement of a document. This proposal adds
	a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]
	</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5789"/>
	<seriesInfo name="DOI" value="10.17487/RFC5789"/>
	</reference>
	<reference anchor="NO-MD5">
	<front>
	<title>Updated Security Considerations for the MD5 Message-Digest an
	d the HMAC-MD5 Algorithms</title>
	<author fullname="S. Turner" initials="S." surname="Turner"/>
	<author fullname="L. Chen" initials="L." surname="Chen"/>
	<date month="March" year="2011"/>
	<abstract>
	<t>This document updates the security considerations for the MD5 m
	essage digest algorithm. It also updates the security considerations for HMAC-MD
	5. This document is not an Internet Standards Track specification; it is publish
	ed for informational purposes.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6151"/>
	<seriesInfo name="DOI" value="10.17487/RFC6151"/>
	</reference>
	<reference anchor="NO-SHA">
	<front>
	<title>Security Considerations for the SHA-0 and SHA-1 Message-Diges
	t Algorithms</title>
	<author fullname="T. Polk" initials="T." surname="Polk"/>
	<author fullname="L. Chen" initials="L." surname="Chen"/>
	<author fullname="S. Turner" initials="S." surname="Turner"/>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<date month="March" year="2011"/>
	<abstract>
	<t>This document includes security considerations for the SHA-0 an
	d SHA-1 message digest algorithm. This document is not an Internet Standards Tra
	ck specification; it is published for informational purposes.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6194"/>
	<seriesInfo name="DOI" value="10.17487/RFC6194"/>
	</reference>
	<reference anchor="SIGNATURES">
	<front>
	<title>HTTP Message Signatures</title>
	<author fullname="Annabelle Backman" initials="A." surname="Backman"
	>
	<organization>Amazon</organization>
	</author>
	<author fullname="Justin Richer" initials="J." surname="Richer">
	<organization>Bespoke Engineering</organization>
	</author>
	<author fullname="Manu Sporny" initials="M." surname="Sporny">
	<organization>Digital Bazaar</organization>
	</author>
	<date day="2" month="May" year="2023"/>
	<abstract>
	<t> This document describes a mechanism for creating, encoding,
	and
	verifying digital signatures or message authentication codes over
	components of an HTTP message. This mechanism supports use cases
	where the full HTTP message may not be known to the signer, and where
	the message may be transformed (e.g., by intermediaries) before
	reaching the verifier. This document also describes a means for
	requesting that a signature be applied to a subsequent HTTP message
	in an ongoing HTTP exchange.


	</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3230.xml"
	</abstract>	/>
	</front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml"
	<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-message-si	/>
	gnatures-17"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5789.xml"
	</reference>	/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6194.xml"
		/>

		<!-- I-D.ietf-httpbis-message-signatures is now RFC 9421 -->
		<reference anchor="RFC9421" target="https://www.rfc-editor.org/info/rfc9421">
		<front>
		<title>HTTP Message Signatures</title>
		<author initials="A." surname="Backman" fullname="Annabelle Backman" role="edito
		r">
		<organization>Amazon</organization>
		</author>
		<author initials="J." surname="Richer" fullname="Justin Richer" role="editor">
		<organization>Bespoke Engineering</organization>
		</author>
		<author initials="M." surname="Sporny" fullname="Manu Sporny">
		<organization>Digital Bazaar</organization>
		</author>
		<date month='February' year='2024'/>
		</front>
		<seriesInfo name="RFC" value="9421"/>
		<seriesInfo name="DOI" value="10.17487/RFC9421"/>
		</reference>

	<reference anchor="UNIX">	<reference anchor="UNIX">
	<front>	<front>
	<title>The Single UNIX Specification, Version 2 - 6 Vol Set for UNIX 98</title>	<title>The Single UNIX Specification, Version 2 - 6 Vol Set for UNIX 98</title>
	<author>	<author>
	<organization>The Open Group</organization>	<organization>The Open Group</organization>
	</author>	</author>

	<date year="1997" month="February"/>	<date year="1998" month="January"/>
	</front>	</front>
	</reference>	</reference>

	<reference anchor="NIST800-32" target="https://nvlpubs.nist.gov/nistpubs
	/Legacy/SP/nistspecialpublication800-32.pdf">	<reference anchor="FIPS186-5" target="https://nvlpubs.nist.gov/nistpubs/
		FIPS/NIST.FIPS.186-5.pdf">
	<front>	<front>

	<title>Introduction to Public Key Technology and the Federal PKI Inf rastructure</title>	<title>Digital Signature Standard (DSS)</title>
	<author>	<author>

	<organization>National Institute of Standards and Technology, U.S. Department of Commerce</organization>	<organization>National Institute of Standards and Technology (NIST )</organization>
	</author>	</author>

	<date year="2001" month="February"/>	<date year="2023" month="February"/>
	</front>	</front>

		<seriesInfo name="FIPS PUB" value="186-5"/>
		<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
	</reference>	</reference>


	<reference anchor="CMU-836068" target="https://www.kb.cert.org/vuls/id/8 36068/">	<reference anchor="CMU-836068" target="https://www.kb.cert.org/vuls/id/8 36068/">
	<front>	<front>

	<title>MD5 Vulnerable to collision attacks</title>	<title>MD5 vulnerable to collision attacks</title>
	<author>	<author>
	<organization>Carnegie Mellon University, Software Engineering Ins titute</organization>	<organization>Carnegie Mellon University, Software Engineering Ins titute</organization>
	</author>	</author>

	<date year="2008" month="December" day="31"/>	<date year="2008" month="December"/>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="IACR-2020-014" target="https://eprint.iacr.org/2020/0 14.pdf">	<reference anchor="IACR-2020-014" target="https://eprint.iacr.org/2020/0 14.pdf">
	<front>	<front>
	<title>SHA-1 is a Shambles</title>	<title>SHA-1 is a Shambles</title>
	<author initials="G." surname="Leurent">	<author initials="G." surname="Leurent">

	<organization>Inria, France</organization>
	</author>	</author>
	<author initials="T." surname="Peyrin">	<author initials="T." surname="Peyrin">

	<organization>Nanyang Technological University, Singapore; Temasek Laboratories, Singapore</organization>
	</author>	</author>

	<date year="2020" month="January" day="05"/>	<date year="2020" month="January"/>
	</front>
	</reference>
	<reference anchor="TLS">
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
	e>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
	<date month="August" year="2018"/>
	<abstract>
	<t>This document specifies version 1.3 of the Transport Layer Secu
	rity (TLS) protocol. TLS allows client/server applications to communicate over t
	he Internet in a way that is designed to prevent eavesdropping, tampering, and m
	essage forgery.</t>
	<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
	77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
	plementations.</t>
	</abstract>
	</front>	</front>

	<seriesInfo name="RFC" value="8446"/>
	<seriesInfo name="DOI" value="10.17487/RFC8446"/>
	</reference>	</reference>

	<reference anchor="I-D.thomson-http-mice">
	<front>
	<title>Merkle Integrity Content Encoding</title>
	<author fullname="Martin Thomson" initials="M." surname="Thomson">
	<organization>Mozilla</organization>
	</author>
	<author fullname="Jeffrey Yasskin" initials="J." surname="Yasskin">
	<organization>Google</organization>
	</author>
	<date day="13" month="August" year="2018"/>
	<abstract>
	<t> This memo introduces a content-coding for HTTP that provides
	progressive integrity for message contents. This integrity
	protection can be evaluated on a partial representation, allowing a
	recipient to process a message as it is delivered while retaining
	strong integrity protection.


	</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"
	</abstract>	/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-thomson-http-mice-03"/>	<!-- [I-D.thomson-http-mice] IESG state Expired -->
	</reference>
	<reference anchor="RFC8188">	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.thomson
	<front>	-http-mice.xml"/>
	<title>Encrypted Content-Encoding for HTTP</title>
	<author fullname="M. Thomson" initials="M." surname="Thomson"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8188.xml"
	<date month="June" year="2017"/>	/>
	<abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7696.xml"
	<t>This memo introduces a content coding for HTTP that allows mess	/>
	age payloads to be encrypted.</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6211.xml"
	</abstract>	/>
	</front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9260.xml"
	<seriesInfo name="RFC" value="8188"/>	/>
	<seriesInfo name="DOI" value="10.17487/RFC8188"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7396.xml"
	</reference>	/>
	<reference anchor="RFC7696">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9457.xml"
	<front>	/>
	<title>Guidelines for Cryptographic Algorithm Agility and Selecting
	Mandatory-to-Implement Algorithms</title>	</references>
	<author fullname="R. Housley" initials="R." surname="Housley"/>
	<date month="November" year="2015"/>
	<abstract>
	<t>Many IETF protocols use cryptographic algorithms to provide con
	fidentiality, integrity, authentication, or digital signature. Communicating pee
	rs must support a common set of cryptographic algorithms for these mechanisms to
	work properly. This memo provides guidelines to ensure that protocols have the
	ability to migrate from one mandatory-to-implement algorithm suite to another ov
	er time.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="201"/>
	<seriesInfo name="RFC" value="7696"/>
	<seriesInfo name="DOI" value="10.17487/RFC7696"/>
	</reference>
	<reference anchor="RFC6211">
	<front>
	<title>Cryptographic Message Syntax (CMS) Algorithm Identifier Prote
	ction Attribute</title>
	<author fullname="J. Schaad" initials="J." surname="Schaad"/>
	<date month="April" year="2011"/>
	<abstract>
	<t>The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certi
	ficates, is vulnerable to algorithm substitution attacks. In an algorithm substi
	tution attack, the attacker changes either the algorithm being used or the param
	eters of the algorithm in order to change the result of a signature verification
	process. In X.509 certificates, the signature algorithm is protected because it
	is duplicated in the TBSCertificate.signature field with the proviso that the v
	alidator is to compare both fields as part of the signature validation process.
	This document defines a new attribute that contains a copy of the relevant algor
	ithm identifiers so that they are protected by the signature or authentication p
	rocess. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6211"/>
	<seriesInfo name="DOI" value="10.17487/RFC6211"/>
	</reference>
	<reference anchor="RFC9260">
	<front>
	<title>Stream Control Transmission Protocol</title>
	<author fullname="R. Stewart" initials="R." surname="Stewart"/>
	<author fullname="M. Tüxen" initials="M." surname="Tüxen"/>
	<author fullname="K. Nielsen" initials="K." surname="Nielsen"/>
	<date month="June" year="2022"/>
	<abstract>
	<t>This document describes the Stream Control Transmission Protoco
	l (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk
	flags registry from RFC 6096 and the specification of the I bit of DATA chunks f
	rom RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document.
	In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted
	by this document.</t>
	<t>SCTP was originally designed to transport Public Switched Telep
	hone Network (PSTN) signaling messages over IP networks. It is also suited to be
	used for other applications, for example, WebRTC.</t>
	<t>SCTP is a reliable transport protocol operating on top of a con
	nectionless packet network, such as IP. It offers the following services to its
	users:</t>
	<t>The design of SCTP includes appropriate congestion avoidance be
	havior and resistance to flooding and masquerade attacks.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9260"/>
	<seriesInfo name="DOI" value="10.17487/RFC9260"/>
	</reference>
	<reference anchor="RFC7396">
	<front>
	<title>JSON Merge Patch</title>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<author fullname="J. Snell" initials="J." surname="Snell"/>
	<date month="October" year="2014"/>
	<abstract>
	<t>This specification defines the JSON merge patch format and proc
	essing rules. The merge patch format is primarily intended for use with the HTTP
	PATCH method as a means of describing a set of modifications to a target resour
	ce's content.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7396"/>
	<seriesInfo name="DOI" value="10.17487/RFC7396"/>
	</reference>
	<reference anchor="RFC7807">
	<front>
	<title>Problem Details for HTTP APIs</title>
	<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
	>
	<author fullname="E. Wilde" initials="E." surname="Wilde"/>
	<date month="March" year="2016"/>
	<abstract>
	<t>This document defines a "problem detail" as a way to carry mach
	ine- readable details of errors in a HTTP response to avoid the need to define n
	ew error response formats for HTTP APIs.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7807"/>
	<seriesInfo name="DOI" value="10.17487/RFC7807"/>
	</reference>
	</references>	</references>

	</references>
	<?line 722?>	<?line 722?>

	<section anchor="resource-representation">	<section anchor="resource-representation">
	<name>Resource Representation and Representation Data</name>	<name>Resource Representation and Representation Data</name>

	<t>This section following examples show how representation metadata, conte	<t>The following examples show how representation metadata, content
	nt	transformations, and methods impact the message and content. These examples a
	transformations, and method impacts on the message and content. These examples a
	not exhaustive.</t>	not exhaustive.</t>
	<t>Unless otherwise indicated, the examples are based on the JSON object < tt>{"hello":	<t>Unless otherwise indicated, the examples are based on the JSON object < tt>{"hello":
	"world"}</tt> followed by an LF. When the content contains non-printable charact ers	"world"}</tt> followed by an LF. When the content contains non-printable charact ers

	(e.g., when it is encoded) it is shown as a sequence of hex-encoded bytes.</t>	(e.g., when it is encoded), it is shown as a sequence of hex-encoded bytes.</t>
	<t>Consider a client that wishes to upload a JSON object using the PUT met	<t>Consider a client that wishes to upload a JSON object using the PUT met
	hod. It	hod.
	could do this using the application/json content type without any content
		It
		could do this using the application/json <tt>Content-Type</tt> without any conte
		nt
	coding.</t>	coding.</t>
	<figure>	<figure>

	<name>Request containing a JSON object without any content coding</name>	<name>Request Containing a JSON Object without Any Content Coding</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	PUT /entries/1234 HTTP/1.1	PUT /entries/1234 HTTP/1.1
	Host: foo.example	Host: foo.example
	Content-Type: application/json	Content-Type: application/json
	Content-Length: 19	Content-Length: 19

	{"hello": "world"}	{"hello": "world"}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<t>However, the use of content coding is quite common. The client could al so upload	<t>However, the use of content coding is quite common. The client could al so upload

	the same data with a gzip coding (<xref section="8.4.1.3" sectionFormat="of" tar get="RFC9110"/>). Note that in	the same data with a GZIP coding (<xref section="8.4.1.3" sectionFormat="of" tar get="RFC9110"/>). Note that in
	this case, the <tt>Content-Length</tt> contains a larger value due to the coding	this case, the <tt>Content-Length</tt> contains a larger value due to the coding
	overheads.</t>	overheads.</t>
	<figure anchor="ex-put-gz">	<figure anchor="ex-put-gz">

	<name>Request containing a gzip-encoded JSON object</name>	<name>Request Containing a GZIP-Encoded JSON Object</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	PUT /entries/1234 HTTP/1.1	PUT /entries/1234 HTTP/1.1
	Host: foo.example	Host: foo.example
	Content-Type: application/json	Content-Type: application/json
	Content-Encoding: gzip	Content-Encoding: gzip
	Content-Length: 39	Content-Length: 39

	1F 8B 08 00 88 41 37 64 00 FF	1F 8B 08 00 88 41 37 64 00 FF
	AB 56 CA 48 CD C9 C9 57 B2 52	AB 56 CA 48 CD C9 C9 57 B2 52
	50 2A CF 2F CA 49 51 AA E5 02	50 2A CF 2F CA 49 51 AA E5 02
	00 D9 E4 31 E7 13 00 00 00	00 D9 E4 31 E7 13 00 00 00
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>

	<t>Sending the gzip coded data without indicating it via <tt>Content-Encod ing</tt> means	<t>Sending the GZIP-coded data without indicating it via <tt>Content-Encod ing</tt> means
	that the content is malformed. In this case, the server can reply with an error. </t>	that the content is malformed. In this case, the server can reply with an error. </t>
	<figure>	<figure>

	<name>Request containing malformed JSON</name>	<name>Request Containing Malformed JSON</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	PUT /entries/1234 HTTP/1.1	PUT /entries/1234 HTTP/1.1
	Host: foo.example	Host: foo.example
	Content-Type: application/json	Content-Type: application/json

	Content-Length: 39	Content-Length: 39

	1F 8B 08 00 88 41 37 64 00 FF	1F 8B 08 00 88 41 37 64 00 FF
	AB 56 CA 48 CD C9 C9 57 B2 52	AB 56 CA 48 CD C9 C9 57 B2 52
	50 2A CF 2F CA 49 51 AA E5 02	50 2A CF 2F CA 49 51 AA E5 02
	00 D9 E4 31 E7 13 00 00 00	00 D9 E4 31 E7 13 00 00 00
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>An error response for a malformed content</name>	<name>An Error Response for Malformed Content</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 400 Bad Request	HTTP/1.1 400 Bad Request


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<t>A Range-Request affects the transferred message content. In this exampl e, the	<t>A Range-Request affects the transferred message content. In this exampl e, the
	client is accessing the resource at <tt>/entries/1234</tt>, which is the JSON ob ject	client is accessing the resource at <tt>/entries/1234</tt>, which is the JSON ob ject
	<tt>{"hello": "world"}</tt> followed by an LF. However, the client has indicated a	<tt>{"hello": "world"}</tt> followed by an LF. However, the client has indicated a
	preferred content coding and a specific byte range.</t>	preferred content coding and a specific byte range.</t>
	<figure>	<figure>

	<name>Request for partial content</name>	<name>Request for Partial Content</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	GET /entries/1234 HTTP/1.1	GET /entries/1234 HTTP/1.1
	Host: foo.example	Host: foo.example
	Accept-Encoding: gzip	Accept-Encoding: gzip
	Range: bytes=1-7	Range: bytes=1-7


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>


	<t>The server satisfies the client request by responding with a partial	<t>The server satisfies the client request by responding with a partial

	representation (equivalent to the first 10 of the JSON object displayed in whole	representation (equivalent to the first 10 bytes of the JSON object displayed in whole
	in <xref target="ex-put-gz"/>).</t>	in <xref target="ex-put-gz"/>).</t>
	<figure>	<figure>

	<name>Partial response from a gzip-encoded representation</name>	<name>Partial Response from a GZIP-Encoded Representation</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 206 Partial Content	HTTP/1.1 206 Partial Content
	Content-Encoding: gzip	Content-Encoding: gzip
	Content-Type: application/json	Content-Type: application/json
	Content-Range: bytes 0-9/39	Content-Range: bytes 0-9/39

	1F 8B 08 00 A5 B4 BD 62 02 FF	1F 8B 08 00 A5 B4 BD 62 02 FF
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<t>Aside from content coding or range requests, the method can also affect the	<t>Aside from content coding or range requests, the method can also affect the
	transferred message content. For example, the response to a HEAD request does	transferred message content. For example, the response to a HEAD request does

	not carry content but in this example case does include a Content-Length; see	not carry content, but this example case includes <tt>Content-Length</tt>; see
	<xref section="8.6" sectionFormat="of" target="RFC9110"/>.</t>	<xref section="8.6" sectionFormat="of" target="RFC9110"/>.</t>
	<figure>	<figure>

	<name>HEAD request</name>	<name>HEAD Request</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HEAD /entries/1234 HTTP/1.1	HEAD /entries/1234 HTTP/1.1
	Host: foo.example	Host: foo.example
	Accept: application/json	Accept: application/json
	Accept-Encoding: gzip	Accept-Encoding: gzip


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>Response to HEAD request (empty content)</name>	<name>Response to HEAD Request (Empty Content)</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 200 OK	HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json
	Content-Encoding: gzip	Content-Encoding: gzip
	Content-Length: 39	Content-Length: 39


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<t>Finally, the semantics of a response might decouple the target URI	<t>Finally, the semantics of a response might decouple the target URI
	from the enclosed representation. In the example below, the client issues a POST	from the enclosed representation. In the example below, the client issues a POST

	request directed to <tt>/authors/</tt> but the response includes a <tt>Content-L	request directed to <tt>/authors/</tt>, but the response includes a <tt>Content-
	ocation</tt>	Location</tt>
	header field that indicates the enclosed representation refers to the	header field indicating that the enclosed representation refers to the
	resource available at <tt>/authors/123</tt>. Note that <tt>Content-Length</tt> i s not sent	resource available at <tt>/authors/123</tt>. Note that <tt>Content-Length</tt> i s not sent
	in this example.</t>	in this example.</t>
	<figure>	<figure>

	<name>POST request</name>	<name>POST Request</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	POST /authors/ HTTP/1.1	POST /authors/ HTTP/1.1
	Host: foo.example	Host: foo.example
	Accept: application/json	Accept: application/json
	Content-Type: application/json	Content-Type: application/json

	{"author": "Camilleri"}	{"author": "Camilleri"}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>Response with Content-Location header</name>	<name>Response with Content-Location Header</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 201 Created	HTTP/1.1 201 Created
	Content-Type: application/json	Content-Type: application/json
	Content-Location: /authors/123	Content-Location: /authors/123
	Location: /authors/123	Location: /authors/123

	{"id": "123", "author": "Camilleri"}	{"id": "123", "author": "Camilleri"}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	<section anchor="examples-unsolicited">	<section anchor="examples-unsolicited">

	<name>Examples of Unsolicited Digest</name>	<name>Examples of Unsolicited <tt>Digest</tt></name>
	<t>The following examples demonstrate interactions where a server responds with a	<t>The following examples demonstrate interactions where a server responds with a

	<tt>Content-Digest</tt> or <tt>Repr-Digest</tt> fields even though the client di d not solicit one using	<tt>Content-Digest</tt> or <tt>Repr-Digest</tt> field, even though the client di d not solicit one using
	<tt>Want-Content-Digest</tt> or <tt>Want-Repr-Digest</tt>.</t>	<tt>Want-Content-Digest</tt> or <tt>Want-Repr-Digest</tt>.</t>
	<t>Some examples include JSON objects in the content.	<t>Some examples include JSON objects in the content.
	For presentation purposes, objects that fit completely within the line-length li mits	For presentation purposes, objects that fit completely within the line-length li mits
	are presented on a single line using compact notation with no leading space.	are presented on a single line using compact notation with no leading space.
	Objects that would exceed line-length limits are presented across multiple lines	Objects that would exceed line-length limits are presented across multiple lines

	(one line per key-value pair) with 2 spaces of leading indentation.</t>	(one line per key-value pair) with two spaces of leading indentation.</t>
	<t>Checksum mechanisms defined in this document are media-type agnostic	<t>Checksum mechanisms defined in this document are media-type agnostic
	and do not provide canonicalization algorithms for specific formats.	and do not provide canonicalization algorithms for specific formats.
	Examples are calculated inclusive of any space.	Examples are calculated inclusive of any space.
	While examples can include both fields,	While examples can include both fields,
	<tt>Content-Digest</tt> and <tt>Repr-Digest</tt> can be returned independently.< /t>	<tt>Content-Digest</tt> and <tt>Repr-Digest</tt> can be returned independently.< /t>
	<section anchor="example-full-representation">	<section anchor="example-full-representation">
	<name>Server Returns Full Representation Data</name>	<name>Server Returns Full Representation Data</name>
	<t>In this example, the message content conveys complete representation data.	<t>In this example, the message content conveys complete representation data.
	This means that in the response, <tt>Content-Digest</tt> and <tt>Repr-Digest</tt >	This means that in the response, <tt>Content-Digest</tt> and <tt>Repr-Digest</tt >

	are both computed over the JSON object <tt>{"hello": "world"}</tt> followed by a n LF, and thus have the same value.</t>	are both computed over the JSON object <tt>{"hello": "world"}</tt> followed by a n LF; thus, they have the same value.</t>
	<figure>	<figure>

	<name>GET request for an item</name>	<name>GET Request for an Item</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	GET /items/123 HTTP/1.1	GET /items/123 HTTP/1.1
	Host: foo.example	Host: foo.example


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>Response with identical Repr-Digest and Content-Digest</name>	<name>Response with Identical <tt>Repr-Digest</tt> and <tt>Content-Dig est</tt></name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	HTTP/1.1 200 OK	HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json
	Content-Length: 19	Content-Length: 19
	Content-Digest: \	Content-Digest: \
	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
	Repr-Digest: \	Repr-Digest: \
	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

	skipping to change at line 1361 ¶	skipping to change at line 1018 ¶
	</figure>	</figure>
	</section>	</section>
	<section anchor="server-returns-no-representation-data">	<section anchor="server-returns-no-representation-data">
	<name>Server Returns No Representation Data</name>	<name>Server Returns No Representation Data</name>
	<t>In this example, a HEAD request is used to retrieve the checksum	<t>In this example, a HEAD request is used to retrieve the checksum
	of a resource.</t>	of a resource.</t>
	<t>The response <tt>Content-Digest</tt> field-value is computed on empty content.	<t>The response <tt>Content-Digest</tt> field-value is computed on empty content.
	<tt>Repr-Digest</tt> is calculated over the JSON object	<tt>Repr-Digest</tt> is calculated over the JSON object
	<tt>{"hello": "world"}</tt> followed by an LF, which is not shown because there is no content.</t>	<tt>{"hello": "world"}</tt> followed by an LF, which is not shown because there is no content.</t>
	<figure>	<figure>

	<name>HEAD request for an item</name>	<name>HEAD Request for an Item</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HEAD /items/123 HTTP/1.1	HEAD /items/123 HTTP/1.1
	Host: foo.example	Host: foo.example


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>Response with both Content-Digest and Digest; empty content</nam e>	<name>Response with Both <tt>Content-Digest</tt> and <tt>Digest</tt> ( Empty Content)</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	HTTP/1.1 200 OK	HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json
	Content-Digest: \	Content-Digest: \
	sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:	sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:
	Repr-Digest: \	Repr-Digest: \
	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	<section anchor="server-returns-partial-representation-data">	<section anchor="server-returns-partial-representation-data">
	<name>Server Returns Partial Representation Data</name>	<name>Server Returns Partial Representation Data</name>
	<t>In this example, the client makes a range request and the server resp onds with	<t>In this example, the client makes a range request and the server resp onds with
	partial content.</t>	partial content.</t>
	<figure>	<figure>

	<name>Request for partial content</name>	<name>Request for Partial Content</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	GET /items/123 HTTP/1.1	GET /items/123 HTTP/1.1
	Host: foo.example	Host: foo.example
	Range: bytes=10-18	Range: bytes=10-18


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>Partial response with both Content-Digest and Repr-Digest</name>	<name>Partial Response with Both <tt>Content-Digest</tt> and <tt>Repr- Digest</tt></name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	HTTP/1.1 206 Partial Content	HTTP/1.1 206 Partial Content
	Content-Type: application/json	Content-Type: application/json
	Content-Range: bytes 10-18/19	Content-Range: bytes 10-18/19
	Content-Digest: \	Content-Digest: \
	sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=:	sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=:
	Repr-Digest: \	Repr-Digest: \
	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

	"world"}	"world"}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<t>In the response message above, note that the	<t>In the response message above, note that the
	<tt>Repr-Digest</tt> and <tt>Content-Digests</tt> are different.	<tt>Repr-Digest</tt> and <tt>Content-Digests</tt> are different.
	The <tt>Repr-Digest</tt> field-value is calculated across the entire JSON object	The <tt>Repr-Digest</tt> field-value is calculated across the entire JSON object

	<tt>{"hello": "world"}</tt> followed by an LF, and the field is</t>	<tt>{"hello": "world"}</tt> followed by an LF, and the field appears as follows: </t>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	Repr-Digest: \	Repr-Digest: \
	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
	]]></sourcecode>	]]></sourcecode>
	<t>However, since the message content is constrained to bytes 10-18,	<t>However, since the message content is constrained to bytes 10-18,
	the <tt>Content-Digest</tt> field-value is calculated over the	the <tt>Content-Digest</tt> field-value is calculated over the

	sequence <tt>"world"}</tt> followed by an LF, thus resulting in</t>	sequence <tt>"world"}</tt> followed by an LF, thus resulting in the following:< /t>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	Content-Digest: \	Content-Digest: \
	sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=:	sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=:
	]]></sourcecode>	]]></sourcecode>
	</section>	</section>
	<section anchor="client-and-server-provide-full-representation-data">	<section anchor="client-and-server-provide-full-representation-data">
	<name>Client and Server Provide Full Representation Data</name>	<name>Client and Server Provide Full Representation Data</name>
	<t>The request contains a <tt>Repr-Digest</tt> field-value calculated on the enclosed	<t>The request contains a <tt>Repr-Digest</tt> field-value calculated on the enclosed

	representation. It also includes an <tt>Accept-Encoding: br</tt> header field th at advertises the	representation. It also includes an <tt>Accept-Encoding: br</tt> header field th at advertises that the
	client supports Brotli encoding.</t>	client supports Brotli encoding.</t>
	<t>The response includes a <tt>Content-Encoding: br</tt> that indicates the selected	<t>The response includes a <tt>Content-Encoding: br</tt> that indicates the selected
	representation is Brotli-encoded. The <tt>Repr-Digest</tt> field-value is theref ore	representation is Brotli-encoded. The <tt>Repr-Digest</tt> field-value is theref ore
	different compared to the request.</t>	different compared to the request.</t>
	<t>For presentation purposes, the response body is displayed as a sequen ce of	<t>For presentation purposes, the response body is displayed as a sequen ce of
	hex-encoded bytes because it contains non-printable characters.</t>	hex-encoded bytes because it contains non-printable characters.</t>
	<figure>	<figure>

	<name>PUT Request with Digest</name>	<name>PUT Request with <tt>Digest</tt></name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	PUT /items/123 HTTP/1.1	PUT /items/123 HTTP/1.1
	Host: foo.example	Host: foo.example
	Content-Type: application/json	Content-Type: application/json
	Accept-Encoding: br	Accept-Encoding: br
	Repr-Digest: \	Repr-Digest: \
	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

	{"hello": "world"}	{"hello": "world"}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>Response with Digest of encoded response</name>	<name>Response with <tt>Digest</tt> of Encoded Response</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	HTTP/1.1 200 OK	HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json
	Content-Location: /items/123	Content-Location: /items/123
	Content-Encoding: br	Content-Encoding: br
	Content-Length: 23	Content-Length: 23
	Repr-Digest: \	Repr-Digest: \
	sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:	sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:

	8B 08 80 7B 22 68 65 6C 6C 6F	8B 08 80 7B 22 68 65 6C 6C 6F
	22 3A 20 22 77 6F 72 6C 64 22	22 3A 20 22 77 6F 72 6C 64 22
	7D 0A 03	7D 0A 03
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	<section anchor="client-provides-full-representation-data-server-provides- no-representation-data">	<section anchor="client-provides-full-representation-data-server-provides- no-representation-data">

	<name>Client Provides Full Representation Data, Server Provides No Repre sentation Data</name>	<name>Client Provides Full Representation Data and Server Provides No Re presentation Data</name>
	<t>The request <tt>Repr-Digest</tt> field-value is calculated on the enc losed content, which	<t>The request <tt>Repr-Digest</tt> field-value is calculated on the enc losed content, which

	is the JSON object <tt>{"hello": "world"}</tt> followed by an LF</t>	is the JSON object <tt>{"hello": "world"}</tt> followed by an LF.</t>
	<t>The response <tt>Repr-Digest</tt> field-value	<t>The response <tt>Repr-Digest</tt> field-value
	depends on the representation metadata header fields, including	depends on the representation metadata header fields, including

	<tt>Content-Encoding: br</tt> even when the response does not contain content.</ t>	<tt>Content-Encoding: br</tt>, even when the response does not contain content.< /t>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	PUT /items/123 HTTP/1.1	PUT /items/123 HTTP/1.1
	Host: foo.example	Host: foo.example
	Content-Type: application/json	Content-Type: application/json
	Content-Length: 19	Content-Length: 19
	Accept-Encoding: br	Accept-Encoding: br
	Repr-Digest: \	Repr-Digest: \
	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:

	{"hello": "world"}	{"hello": "world"}
	]]></sourcecode>	]]></sourcecode>
	<figure>	<figure>

	<name>Empty response with Digest</name>	<name>Empty Response with <tt>Digest</tt></name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 204 No Content	HTTP/1.1 204 No Content
	Content-Type: application/json	Content-Type: application/json
	Content-Encoding: br	Content-Encoding: br
	Repr-Digest: sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:	Repr-Digest: sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	<section anchor="client-and-server-provide-full-representation-data-1">	<section anchor="client-and-server-provide-full-representation-data-1">
	<name>Client and Server Provide Full Representation Data</name>	<name>Client and Server Provide Full Representation Data</name>
	<t>The response contains two digest values using different algorithms.</ t>	<t>The response contains two digest values using different algorithms.</ t>
	<t>For presentation purposes, the response body is displayed as a sequen ce of	<t>For presentation purposes, the response body is displayed as a sequen ce of
	hex-encoded bytes because it contains non-printable characters.</t>	hex-encoded bytes because it contains non-printable characters.</t>
	<figure>	<figure>

	<name>PUT Request with Digest</name>	<name>PUT Request with <tt>Digest</tt></name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	PUT /items/123 HTTP/1.1	PUT /items/123 HTTP/1.1
	Host: foo.example	Host: foo.example
	Content-Type: application/json	Content-Type: application/json
	Accept-Encoding: br	Accept-Encoding: br
	Repr-Digest: \	Repr-Digest: \
	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:

	{"hello": "world"}	{"hello": "world"}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>Response with Digest of Encoded Content</name>	<name>Response with <tt>Digest</tt> of Encoded Content</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	HTTP/1.1 200 OK	HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json
	Content-Encoding: br	Content-Encoding: br
	Content-Location: /items/123	Content-Location: /items/123
	Repr-Digest: \	Repr-Digest: \
	sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\	sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\
	sha-512=:db7fdBbgZMgX1Wb2MjA8zZj+rSNgfmDCEEXM8qLWfpfoNY0sCpHAzZbj\	sha-512=:db7fdBbgZMgX1Wb2MjA8zZj+rSNgfmDCEEXM8qLWfpfoNY0sCpHAzZbj\
	09X1/7HAb7Od5Qfto4QpuBsFbUO3dQ==:	09X1/7HAb7Od5Qfto4QpuBsFbUO3dQ==:

	8B 08 80 7B 22 68 65 6C 6C 6F	8B 08 80 7B 22 68 65 6C 6C 6F
	22 3A 20 22 77 6F 72 6C 64 22	22 3A 20 22 77 6F 72 6C 64 22
	7D 0A 03	7D 0A 03
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	<section anchor="post-not-request-uri">	<section anchor="post-not-request-uri">

	<name>POST Response does not Reference the Request URI</name>	<name>POST Response Does Not Reference the Request URI</name>
	<t>The request <tt>Repr-Digest</tt> field-value is computed on the enclo sed representation	<t>The request <tt>Repr-Digest</tt> field-value is computed on the enclo sed representation
	(see <xref target="state-changing-requests"/>), which is the JSON object <tt>{"t itle": "New	(see <xref target="state-changing-requests"/>), which is the JSON object <tt>{"t itle": "New
	Title"}</tt> followed by an LF.</t>	Title"}</tt> followed by an LF.</t>
	<t>The representation enclosed in the response is a multiline JSON objec t followed by an LF.	<t>The representation enclosed in the response is a multiline JSON objec t followed by an LF.
	It refers to the resource identified by	It refers to the resource identified by
	<tt>Content-Location</tt> (see <xref section="6.4.2" sectionFormat="of" target=" RFC9110"/>);	<tt>Content-Location</tt> (see <xref section="6.4.2" sectionFormat="of" target=" RFC9110"/>);

	an application can thus use <tt>Repr-Digest</tt> in association with the resourc e	thus, an application can use <tt>Repr-Digest</tt> in association with the resour ce
	referenced by <tt>Content-Location</tt>.</t>	referenced by <tt>Content-Location</tt>.</t>
	<figure>	<figure>

	<name>POST Request with Digest</name>	<name>POST Request with <tt>Digest</tt></name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	POST /books HTTP/1.1	POST /books HTTP/1.1
	Host: foo.example	Host: foo.example
	Content-Type: application/json	Content-Type: application/json
	Accept: application/json	Accept: application/json
	Accept-Encoding: identity	Accept-Encoding: identity
	Repr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:	Repr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:

	{"title": "New Title"}	{"title": "New Title"}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>Response with Digest of Resource</name>	<name>Response with <tt>Digest</tt> of Resource</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 201 Created	HTTP/1.1 201 Created
	Content-Type: application/json	Content-Type: application/json
	Content-Location: /books/123	Content-Location: /books/123
	Location: /books/123	Location: /books/123
	Repr-Digest: sha-256=:uVSlinTTdQUwm2On4k8TJUikGN1bf/Ds8WPX4oe0h9I=:	Repr-Digest: sha-256=:uVSlinTTdQUwm2On4k8TJUikGN1bf/Ds8WPX4oe0h9I=:

	{	{
	"id": "123",	"id": "123",
	"title": "New Title"	"title": "New Title"

	skipping to change at line 1597 ¶	skipping to change at line 1250 ¶
	<name>POST Response Describes the Request Status</name>	<name>POST Response Describes the Request Status</name>
	<t>The request <tt>Repr-Digest</tt> field-value is computed on the enclo sed representation (see	<t>The request <tt>Repr-Digest</tt> field-value is computed on the enclo sed representation (see
	<xref target="state-changing-requests"/>), which is the JSON object <tt>{"title" : "New	<xref target="state-changing-requests"/>), which is the JSON object <tt>{"title" : "New
	Title"}</tt> followed by an LF.</t>	Title"}</tt> followed by an LF.</t>
	<t>The representation enclosed in the response describes the status of t he request,	<t>The representation enclosed in the response describes the status of t he request,
	so <tt>Repr-Digest</tt> is computed on that enclosed representation. It is a mul tiline	so <tt>Repr-Digest</tt> is computed on that enclosed representation. It is a mul tiline
	JSON object followed by an LF.</t>	JSON object followed by an LF.</t>
	<t>Response <tt>Repr-Digest</tt> has no explicit relation with the resou rce referenced by	<t>Response <tt>Repr-Digest</tt> has no explicit relation with the resou rce referenced by
	<tt>Location</tt>.</t>	<tt>Location</tt>.</t>
	<figure>	<figure>

	<name>POST Request with Digest</name>	<name>POST Request with <tt>Digest</tt></name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	POST /books HTTP/1.1	POST /books HTTP/1.1
	Host: foo.example	Host: foo.example
	Content-Type: application/json	Content-Type: application/json
	Accept: application/json	Accept: application/json
	Accept-Encoding: identity	Accept-Encoding: identity
	Repr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:	Repr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:

	{"title": "New Title"}	{"title": "New Title"}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>Response with Digest of Representation</name>	<name>Response with <tt>Digest</tt> of Representation</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 201 Created	HTTP/1.1 201 Created
	Content-Type: application/json	Content-Type: application/json
	Repr-Digest: sha-256=:yXIGDTN5VrfoyisKlXgRKUHHMs35SNtyC3szSz1dbO8=:	Repr-Digest: sha-256=:yXIGDTN5VrfoyisKlXgRKUHHMs35SNtyC3szSz1dbO8=:
	Location: /books/123	Location: /books/123

	{	{
	"status": "created",	"status": "created",
	"id": "123",	"id": "123",
	"ts": 1569327729,	"ts": 1569327729,
	"instance": "/books/123"	"instance": "/books/123"
	}	}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	<section anchor="digest-with-patch">	<section anchor="digest-with-patch">

	<name>Digest with PATCH</name>	<name><tt>Digest</tt> with PATCH</name>
	<t>This case is analogous to a POST request where the target resource re flects the	<t>This case is analogous to a POST request where the target resource re flects the
	target URI.</t>	target URI.</t>
	<t>The PATCH request uses the <tt>application/merge-patch+json</tt> medi a type defined in	<t>The PATCH request uses the <tt>application/merge-patch+json</tt> medi a type defined in

	<xref target="RFC7396"/>. <tt>Repr-Digest</tt> is calculated on the content, whi ch corresponds to the	<xref target="RFC7396"/>. <tt>Repr-Digest</tt> is calculated on the content that corresponds to the
	patch document and is the JSON object <tt>{"title": "New Title"}</tt> followed b y an	patch document and is the JSON object <tt>{"title": "New Title"}</tt> followed b y an
	LF.</t>	LF.</t>
	<t>The response <tt>Repr-Digest</tt> field-value is computed on the comp lete representation of the patched	<t>The response <tt>Repr-Digest</tt> field-value is computed on the comp lete representation of the patched
	resource. It is a multiline JSON object followed by an LF.</t>	resource. It is a multiline JSON object followed by an LF.</t>
	<figure anchor="fig-patch">	<figure anchor="fig-patch">

	<name>PATCH Request with Digest</name>	<name>PATCH Request with <tt>Digest</tt></name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	PATCH /books/123 HTTP/1.1	PATCH /books/123 HTTP/1.1
	Host: foo.example	Host: foo.example
	Content-Type: application/merge-patch+json	Content-Type: application/merge-patch+json
	Accept: application/json	Accept: application/json
	Accept-Encoding: identity	Accept-Encoding: identity
	Repr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:	Repr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:

	{"title": "New Title"}	{"title": "New Title"}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>Response with Digest of Representation</name>	<name>Response with <tt>Digest</tt> of Representation</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 200 OK	HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json
	Repr-Digest: sha-256=:uVSlinTTdQUwm2On4k8TJUikGN1bf/Ds8WPX4oe0h9I=:	Repr-Digest: sha-256=:uVSlinTTdQUwm2On4k8TJUikGN1bf/Ds8WPX4oe0h9I=:

	{	{
	"id": "123",	"id": "123",
	"title": "New Title"	"title": "New Title"
	}	}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>

	<t>Note that a <tt>204 No Content</tt> response without content but with	<t>Note that a <tt>204 No Content</tt> response without content, but wit
	the same	h the same
	<tt>Repr-Digest</tt> field-value would have been legitimate too.	<tt>Repr-Digest</tt> field-value, would have been legitimate too.
	In that case, <tt>Content-Digest</tt> would have been computed on an empty conte nt.</t>	In that case, <tt>Content-Digest</tt> would have been computed on an empty conte nt.</t>
	</section>	</section>
	<section anchor="error-responses">	<section anchor="error-responses">

	<name>Error responses</name>	<name>Error Responses</name>
	<t>In error responses, the representation data does not necessarily refe r to the	<t>In error responses, the representation data does not necessarily refe r to the
	target resource. Instead, it refers to the representation of the error.</t>	target resource. Instead, it refers to the representation of the error.</t>
	<t>In the following example, a client sends the same request from <xref target="fig-patch"/> to	<t>In the following example, a client sends the same request from <xref target="fig-patch"/> to
	patch the resource located at /books/123. However, the resource does not exist	patch the resource located at /books/123. However, the resource does not exist
	and the server generates a 404 response with a body that describes the error in	and the server generates a 404 response with a body that describes the error in

	accordance with <xref target="RFC7807"/>.</t>	accordance with <xref target="RFC9457"/>.</t>
	<t>The response <tt>Repr-Digest</tt> field-value is computed on this enc losed representation.	<t>The response <tt>Repr-Digest</tt> field-value is computed on this enc losed representation.
	It is a multiline JSON object followed by an LF.</t>	It is a multiline JSON object followed by an LF.</t>
	<figure>	<figure>

	<name>Response with Digest of Error Representation</name>	<name>Response with <tt>Digest</tt> of Error Representation</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 404 Not Found	HTTP/1.1 404 Not Found
	Content-Type: application/problem+json	Content-Type: application/problem+json
	Repr-Digest: sha-256=:EXB0S2VF2H7ijkAVJkH1Sm0pBho0iDZcvVUHHXTTZSA=:	Repr-Digest: sha-256=:EXB0S2VF2H7ijkAVJkH1Sm0pBho0iDZcvVUHHXTTZSA=:

	{	{
	"title": "Not Found",	"title": "Not Found",
	"detail": "Cannot PATCH a non-existent resource",	"detail": "Cannot PATCH a non-existent resource",
	"status": 404	"status": 404
	}	}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	<section anchor="use-with-trailer-fields-and-transfer-coding">	<section anchor="use-with-trailer-fields-and-transfer-coding">
	<name>Use with Trailer Fields and Transfer Coding</name>	<name>Use with Trailer Fields and Transfer Coding</name>
	<t>An origin server sends <tt>Repr-Digest</tt> as trailer field, so it c an calculate digest-value	<t>An origin server sends <tt>Repr-Digest</tt> as trailer field, so it c an calculate digest-value
	while streaming content and thus mitigate resource consumption.	while streaming content and thus mitigate resource consumption.
	The <tt>Repr-Digest</tt> field-value is the same as in <xref target="example-ful l-representation"/> because <tt>Repr-Digest</tt> is designed to	The <tt>Repr-Digest</tt> field-value is the same as in <xref target="example-ful l-representation"/> because <tt>Repr-Digest</tt> is designed to
	be independent of the use of one or more transfer codings (see <xref target="rep resentation-digest"/>).</t>	be independent of the use of one or more transfer codings (see <xref target="rep resentation-digest"/>).</t>

	<t>In the response content below, the string "\r\n" represent the bytes CRLF.</t>	<t>In the response content below, the string "\r\n" represents the CRLF bytes.</t>
	<figure>	<figure>
	<name>GET Request</name>	<name>GET Request</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	GET /items/123 HTTP/1.1	GET /items/123 HTTP/1.1
	Host: foo.example	Host: foo.example


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>Chunked Response with Digest</name>	<name>Chunked Response with <tt>Digest</tt></name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	HTTP/1.1 200 OK	HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json
	Transfer-Encoding: chunked	Transfer-Encoding: chunked

	Trailer: Digest	Trailer: Repr-Digest

	8\r\n	8\r\n
	{"hello"\r\n	{"hello"\r\n
	8\r\n	8\r\n
	: "world\r\n	: "world\r\n
	3\r\n	3\r\n
	"}\n\r\n	"}\n\r\n
	0\r\n	0\r\n
	Repr-Digest: \	Repr-Digest: \
	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:\r\n	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:\r\n

	skipping to change at line 1725 ¶	skipping to change at line 1377 ¶

	8\r\n	8\r\n
	{"hello"\r\n	{"hello"\r\n
	8\r\n	8\r\n
	: "world\r\n	: "world\r\n
	3\r\n	3\r\n
	"}\n\r\n	"}\n\r\n
	0\r\n	0\r\n
	Repr-Digest: \	Repr-Digest: \
	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:\r\n	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:\r\n


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	</section>	</section>
	<section anchor="examples-solicited">	<section anchor="examples-solicited">

	<name>Examples of Want-Repr-Digest Solicited Digest</name>	<name>Examples of <tt>Want-Repr-Digest</tt> Solicited <tt>Digest</tt></nam e>
	<t>The following examples demonstrate interactions where a client solicits a	<t>The following examples demonstrate interactions where a client solicits a
	<tt>Repr-Digest</tt> using <tt>Want-Repr-Digest</tt>.	<tt>Repr-Digest</tt> using <tt>Want-Repr-Digest</tt>.
	The behavior of <tt>Content-Digest</tt> and <tt>Want-Content-Digest</tt> is iden tical.</t>	The behavior of <tt>Content-Digest</tt> and <tt>Want-Content-Digest</tt> is iden tical.</t>
	<t>Some examples include JSON objects in the content.	<t>Some examples include JSON objects in the content.
	For presentation purposes, objects that fit completely within the line-length li mits	For presentation purposes, objects that fit completely within the line-length li mits
	are presented on a single line using compact notation with no leading space.	are presented on a single line using compact notation with no leading space.
	Objects that would exceed line-length limits are presented across multiple lines	Objects that would exceed line-length limits are presented across multiple lines

	(one line per key-value pair) with 2 spaces of leading indentation.</t>	(one line per key-value pair) with two spaces of leading indentation.</t>
	<t>Checksum mechanisms described in this document are media-type agnostic	<t>Checksum mechanisms described in this document are media-type agnostic
	and do not provide canonicalization algorithms for specific formats.	and do not provide canonicalization algorithms for specific formats.
	Examples are calculated inclusive of any space.</t>	Examples are calculated inclusive of any space.</t>
	<section anchor="server-selects-clients-least-preferred-algorithm">	<section anchor="server-selects-clients-least-preferred-algorithm">
	<name>Server Selects Client's Least Preferred Algorithm</name>	<name>Server Selects Client's Least Preferred Algorithm</name>

	<t>The client requests a digest, preferring "sha". The server is free to reply with	<t>The client requests a digest and prefers "sha". The server is free to reply with
	"sha-256" anyway.</t>	"sha-256" anyway.</t>
	<figure>	<figure>

	<name>GET Request with Want-Repr-Digest</name>	<name>GET Request with <tt>Want-Repr-Digest</tt></name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	GET /items/123 HTTP/1.1	GET /items/123 HTTP/1.1
	Host: foo.example	Host: foo.example
	Want-Repr-Digest: sha-256=3, sha=10	Want-Repr-Digest: sha-256=3, sha=10


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>
	<name>Response with Different Algorithm</name>	<name>Response with Different Algorithm</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	HTTP/1.1 200 OK	HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json
	Repr-Digest: \	Repr-Digest: \
	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:	sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:

	{"hello": "world"}	{"hello": "world"}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	<section anchor="ex-server-selects-unsupported-algorithm">	<section anchor="ex-server-selects-unsupported-algorithm">
	<name>Server Selects Algorithm Unsupported by Client</name>	<name>Server Selects Algorithm Unsupported by Client</name>
	<t>The client requests a "sha" digest because that is the only algorithm it	<t>The client requests a "sha" digest because that is the only algorithm it
	supports. The server is not obliged to produce a response containing a "sha"	supports. The server is not obliged to produce a response containing a "sha"

	digest, it instead uses a different algorithm.</t>	digest; it instead uses a different algorithm.</t>
	<figure>	<figure>

	<name>GET Request with Want-Repr-Digest</name>	<name>GET Request with <tt>Want-Repr-Digest</tt></name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	GET /items/123 HTTP/1.1	GET /items/123 HTTP/1.1
	Host: foo.example	Host: foo.example
	Want-Repr-Digest: sha=10	Want-Repr-Digest: sha=10


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>
	<name>Response with Unsupported Algorithm</name>	<name>Response with Unsupported Algorithm</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	HTTP/1.1 200 OK	HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json
	Repr-Digest: \	Repr-Digest: \

	skipping to change at line 1803 ¶	skipping to change at line 1452 ¶
	yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:	yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:

	{"hello": "world"}	{"hello": "world"}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	<section anchor="server-does-not-support-client-algorithm-and-returns-an-e rror">	<section anchor="server-does-not-support-client-algorithm-and-returns-an-e rror">
	<name>Server Does Not Support Client Algorithm and Returns an Error</nam e>	<name>Server Does Not Support Client Algorithm and Returns an Error</nam e>
	<t><xref target="ex-server-selects-unsupported-algorithm"/> is an exampl e where a server ignores	<t><xref target="ex-server-selects-unsupported-algorithm"/> is an exampl e where a server ignores
	the client's preferred digest algorithm.	the client's preferred digest algorithm.

	Alternatively a server can also reject	Alternatively, a server can also reject
	the request and return a response with	the request and return a response with

	error status code such as 4xx or 5xx.	an error status code such as 4xx or 5xx.
	This specification does not prescribe	This specification does not prescribe
	any requirement on status code selection;	any requirement on status code selection;

	the follow example illustrates one possible	the following example illustrates one possible
	option.</t>	option.</t>
	<t>In this example, the client requests a "sha" <tt>Repr-Digest</tt>, an d the server returns an	<t>In this example, the client requests a "sha" <tt>Repr-Digest</tt>, an d the server returns an

	error with problem details <xref target="RFC7807"/> contained in the content. Th e problem	error with problem details <xref target="RFC9457"/> contained in the content. Th e problem
	details contain a list of the hashing algorithms that the server supports. This	details contain a list of the hashing algorithms that the server supports. This

	is purely an example, this specification does not define any format or	is purely an example; this specification does not define any format or
	requirements for such content.</t>	requirements for such content.</t>
	<figure>	<figure>

	<name>GET Request with Want-Repr-Digest</name>	<name>GET Request with <tt>Want-Repr-Digest</tt></name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	GET /items/123 HTTP/1.1	GET /items/123 HTTP/1.1
	Host: foo.example	Host: foo.example
	Want-Repr-Digest: sha=10	Want-Repr-Digest: sha=10


	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	<figure>	<figure>

	<name>Response advertising the supported algorithms</name>	<name>Response Advertising the Supported Algorithms</name>
	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 400 Bad Request	HTTP/1.1 400 Bad Request
	Content-Type: application/problem+json	Content-Type: application/problem+json

	{	{
	"title": "Bad Request",	"title": "Bad Request",
	"detail": "Supported hashing algorithms: sha-256, sha-512",	"detail": "Supported hashing algorithms: sha-256, sha-512",
	"status": 400	"status": 400
	}	}
	]]></sourcecode>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	</section>	</section>
	<section anchor="sample-digest-values">	<section anchor="sample-digest-values">

	<name>Sample Digest Values</name>	<name>Sample <tt>Digest</tt> Values</name>
	<t>This section shows examples of digest values for different hashing algo rithms.	<t>This section shows examples of digest values for different hashing algo rithms.
	The input value is the JSON object <tt>{"hello": "world"}</tt>. The digest value s are	The input value is the JSON object <tt>{"hello": "world"}</tt>. The digest value s are
	each produced by running the relevant hashing algorithm over the input and	each produced by running the relevant hashing algorithm over the input and

	running the output bytes through <tt>Byte Sequence</tt> serialization; see <xref	running the output bytes through Byte Sequence serialization; see <xref section=
	section="4.1.8" sectionFormat="of" target="STRUCTURED-FIELDS"/>.</t>	"4.1.8" sectionFormat="of" target="RFC8941"/>.</t>
	<artwork><![CDATA[	<sourcecode><![CDATA[
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	sha-512 - :WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+TaPm+\	sha-512 - :WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+TaPm+\
	AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:	AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:

	sha-256 - :X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:	sha-256 - :X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:

	md5 - :Sd/dVLAcvNLSq16eXua5uQ==:	md5 - :Sd/dVLAcvNLSq16eXua5uQ==:

	sha - :07CavjDP4u3/TungoUHJO/Wzr4c=:	sha - :07CavjDP4u3/TungoUHJO/Wzr4c=:

	unixsum - :GQU=:	unixsum - :GQU=:

	unixcksum - :7zsHAA==:	unixcksum - :7zsHAA==:

	adler - :OZkGFw==:	adler - :OZkGFw==:

	crc32c - :Q3lHIA==:	crc32c - :Q3lHIA==:

	]]></artwork>	]]></sourcecode>
	</section>	</section>
	<section anchor="migrating">	<section anchor="migrating">
	<name>Migrating from RFC 3230</name>	<name>Migrating from RFC 3230</name>
	<t>HTTP digests are computed by applying a hashing algorithm to input data .	<t>HTTP digests are computed by applying a hashing algorithm to input data .

	RFC 3230 defined the input data as an "instance", a term it also defined.	<xref target="RFC3230"/> defined the input data as an "instance", a term it also
	The concept of instance has since been superseded by the HTTP semantic term "rep	defined.
	resentation".	The concept of an instance has since been superseded by the HTTP semantic term "
	It is understood that some implementations of RFC 3230	representation".
		It is understood that some implementations of <xref target="RFC3230"/>
	mistook "instance" to mean HTTP content.	mistook "instance" to mean HTTP content.

	Using content for the Digest field is an error	Using content for the <tt>Digest</tt> field is an error
	that leads to interoperability problems between peers that implement RFC 3230.</	that leads to interoperability problems between peers that implement <xref targe
	t>	t="RFC3230"/>.</t>
	<t>RFC 3230 was only ever intended	<t><xref target="RFC3230"/> was only ever intended
	to use what HTTP now defines as selected representation data.	to use what HTTP now defines as selected representation data.
	The semantic concept of digest and representation are explained	The semantic concept of digest and representation are explained

	alongside the definition of <xref target="representation-digest">the Repr-Digest	alongside the definition of the <tt>Repr-Digest</tt> field (<xref target="repres
	field</xref>.</t>	entation-digest"/>).</t>
	<t>While the syntax of Digest and Repr-Digest are different,	<t>While the syntax of <tt>Digest</tt> and <tt>Repr-Digest</tt> are differ
	the considerations and examples this document gives for Repr-Digest	ent,
	apply equally to Digest because they operate on the same input data;	the considerations and examples this document gives for <tt>Repr-Digest</tt>
		apply equally to <tt>Digest</tt> because they operate on the same input data;
	see Sections <xref format="counter" target="state-changing-requests"/>, <xref fo rmat="counter" target="security"/> and <xref format="counter" target="usage-in-s ignatures"/>.</t>	see Sections <xref format="counter" target="state-changing-requests"/>, <xref fo rmat="counter" target="security"/> and <xref format="counter" target="usage-in-s ignatures"/>.</t>

	<t>RFC 3230 could never communicate	<t><xref target="RFC3230"/> could never communicate
	the digest of HTTP message content in the Digest field;	the digest of HTTP message content in the <tt>Digest</tt> field;
	Content-Digest now provides that capability.</t>	<tt>Content-Digest</tt> now provides that capability.</t>
	<t>RFC 3230 allowed algorithms to define their output encoding format for	<t><xref target="RFC3230"/> allowed algorithms to define their output enco
	use with	ding format for use with
	the Digest field. This resulted in a mix of formats such as base64, hex or	the <tt>Digest</tt> field. This resulted in a mix of formats such as base64, hex
	decimal. By virtue of using Structured fields, Content-Digest and Repr-Digest	, or
		decimal. By virtue of using Structured Fields, <tt>Content-Digest</tt>, and <tt>
		Repr-Digest</tt>
	use only a single encoding format. Further explanation and examples are provided in <xref target="sample-digest-values"/>.</t>	use only a single encoding format. Further explanation and examples are provided in <xref target="sample-digest-values"/>.</t>
	</section>	</section>
	<section numbered="false" anchor="acknowledgements">	<section numbered="false" anchor="acknowledgements">
	<name>Acknowledgements</name>	<name>Acknowledgements</name>
	<t>This document is based on ideas from <xref target="RFC3230"/>, so thank s	<t>This document is based on ideas from <xref target="RFC3230"/>, so thank s

	to Jeff Mogul and Arthur Van Hoff for their great work.	to <contact fullname="Jeff Mogul"/> and <contact fullname="Arthur Van Hoff"/> fo
	The original idea of refreshing RFC3230 arose from an interesting	r their great work.
	discussion with Mark Nottingham, Jeffrey Yasskin, and Martin Thomson when review	The original idea of refreshing <xref target="RFC3230"/> arose from an interesti
	ing	ng
		discussion with <contact fullname="Mark Nottingham"/>, <contact fullname="Jeffre
		y Yasskin"/>, and <contact fullname="Martin Thomson"/> when reviewing
	the MICE content coding.</t>	the MICE content coding.</t>

	<t>Thanks to Julian Reschke for his valuable contributions to this documen t,	<t>Thanks to <contact fullname="Julian Reschke"/> for his valuable contrib utions to this document,
	and to the following contributors that have helped improve this specification by reporting bugs,	and to the following contributors that have helped improve this specification by reporting bugs,
	asking smart questions, drafting or reviewing text, and evaluating open issues:	asking smart questions, drafting or reviewing text, and evaluating open issues:

	Mike Bishop,	<contact fullname="Mike Bishop"/>,
	Brian Campbell,	<contact fullname="Brian Campbell"/>,
	Matthew Kerwin,	<contact fullname="Matthew Kerwin"/>,
	James Manger,	<contact fullname="James Manger"/>,
	Tommy Pauly,	<contact fullname="Tommy Pauly"/>,
	Sean Turner,	<contact fullname="Sean Turner"/>,
	Justin Richer,	<contact fullname="Justin Richer"/>,
	and Erik Wilde.</t>	and <contact fullname="Erik Wilde"/>.</t>
	</section>
	<section numbered="false" removeInRFC="true" anchor="code-samples">
	<name>Code Samples</name>
	<t>How can I generate and validate the digest values, computed over the JS
	ON object
	<tt>{"hello": "world"}</tt> followed by an LF, shown in the examples throughout
	this
	document?</t>
	<t>The following python3 code can be used to generate digests for JSON obj
	ects
	using SHA algorithms for a range of encodings. Note that these are formatted as
	base64. This function could be adapted to other algorithms and should take into
	account their specific formatting rules.</t>
	<artwork><![CDATA[
	import base64, json, hashlib, brotli, logging
	log = logging.getLogger()

	def digest_bytes(bytes_, algorithm=hashlib.sha256):
	checksum_bytes = algorithm(bytes_).digest()
	log.warning("Log bytes: \n[%r]", bytes_)
	return base64.encodebytes(checksum_bytes).strip()

	def digest(bytes_, encoding=lambda x: x, algorithm=hashlib.sha256):
	content_encoded = encoding(bytes_)
	return digest_bytes(content_encoded, algorithm)

	bytes_ = b'{"hello": "world"}\n'

	print("Encoding \| hashing algorithm \| digest-value")
	print("Identity \| sha256 \|", digest(bytes_))
	# Encoding \| hashing algorithm \| digest-value
	# Identity \| sha256 \| RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=

	print("Encoding \| hashing algorithm \| digest-value")
	print("Brotli \| sha256 \|", digest(bytes_, encoding=brotli.compress))
	# Encoding \| hashing algorithm \| digest-value
	# Brotli \| sha256 \| d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=

	print("Encoding \| hashing algorithm \| digest-value")
	print("Identity \| sha512 \|", digest(bytes_, algorithm=hashlib.sha512))
	print("Brotli \| sha512 \|", digest(bytes_, algorithm=hashlib.sha512,
	encoding=brotli.compress))
	# Encoding \| hashing algorithm \| digest-value
	# Identity \| sha512 \|b'YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP'
	# '+pgk4vf2aCsyRZOtw8MjkM7iw7yZ/WkppmM44T3qg=='

	# Brotli \| sha512 \| b'db7fdBbgZMgX1Wb2MjA8zZj+rSNgfmDCEEXM8qLWfpfoNY'
	# '0sCpHAzZbj09X1/7HAb7Od5Qfto4QpuBsFbUO3dQ=='

	]]></artwork>
	</section>
	<section numbered="false" removeInRFC="true" anchor="changes">
	<name>Changes</name>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	12">
	<name>Since draft-ietf-httpbis-digest-headers-12</name>
	<ul spacing="normal">
	<li>Be clearer that applications can enforce additional requirements w
	rt digest</li>
	<li>Change algorithm status names: s/standard/active, s/insecure/depre
	cated</li>
	<li>Remove "reserved" algorithm status</li>
	<li>Provide clear guidance about the use of standard or deprecated alg
	orithms</li>
	<li>Editorial or minor changes</li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	11">
	<name>Since draft-ietf-httpbis-digest-headers-11</name>
	<ul spacing="normal">
	<li>Editorial or minor changes</li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	10">
	<name>Since draft-ietf-httpbis-digest-headers-10</name>
	<ul spacing="normal">
	<li>Editorial or minor changes</li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	09">
	<name>Since draft-ietf-httpbis-digest-headers-09</name>
	<ul spacing="normal">
	<li>Editorial or minor changes</li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	08">
	<name>Since draft-ietf-httpbis-digest-headers-08</name>
	<ul spacing="normal">
	<li>Add note about migrating from RFC 3230. #1968, #1971</li>
	<li>Clarify what Want-* means in responses. #2097</li>
	<li>Editorial changes to structure and to align to HTTP style guide.</
	li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	07">
	<name>Since draft-ietf-httpbis-digest-headers-07</name>
	<ul spacing="normal">
	<li>Introduced Repr-Digest and Want-Repr-Digest, and deprecated
	Digest and Want-Digest. Use of Structured Fields. #1993, #1919</li>
	<li>IANA refactoring. #1983</li>
	<li>No normative text in security considerations. #1972</li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	06">
	<name>Since draft-ietf-httpbis-digest-headers-06</name>
	<ul spacing="normal">
	<li>Remove id-sha-256 and id-sha-512 from the list of supported algori
	thms #855</li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	05">
	<name>Since draft-ietf-httpbis-digest-headers-05</name>
	<ul spacing="normal">
	<li>Reboot digest-algorithm values registry #1567</li>
	<li>Add Content-Digest #1542</li>
	<li>Remove SRI section #1478</li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	04">
	<name>Since draft-ietf-httpbis-digest-headers-04</name>
	<ul spacing="normal">
	<li>Improve SRI section #1354</li>
	<li>About duplicate digest-algorithms #1221</li>
	<li>Improve security considerations #852</li>
	<li>md5 and sha deprecation references #1392</li>
	<li>Obsolete 3230 #1395</li>
	<li>Editorial #1362</li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	03">
	<name>Since draft-ietf-httpbis-digest-headers-03</name>
	<ul spacing="normal">
	<li>Reference semantics-12</li>
	<li>Detail encryption quirks</li>
	<li>Details on Algorithm agility #1250</li>
	<li>Obsolete parameters #850</li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	02">
	<name>Since draft-ietf-httpbis-digest-headers-02</name>
	<ul spacing="normal">
	<li>Deprecate SHA-1 #1154</li>
	<li>Avoid id-* with encrypted content</li>
	<li>Digest is independent of MESSAGING and HTTP/1.1 is not normative #
	1215</li>
	<li>Identity is not a valid field value for content-encoding #1223</li
	>
	<li>Mention trailers #1157</li>
	<li>Reference httpbis-semantics #1156</li>
	<li>Add contentMD5 as an obsoleted digest-algorithm #1249</li>
	<li>Use lowercase digest-algorithms names in the doc and in the digest
	-algorithm IANA table.</li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	01">
	<name>Since draft-ietf-httpbis-digest-headers-01</name>
	<ul spacing="normal">
	<li>Digest of error responses is computed on the error representation-
	data #1004</li>
	<li>Effect of HTTP semantics on payload and message body moved to appe
	ndix #1122</li>
	<li>Editorial refactoring, moving headers sections up. #1109-#1112, #1
	116,
	#1117, #1122-#1124</li>
	</ul>
	</section>
	<section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-
	00">
	<name>Since draft-ietf-httpbis-digest-headers-00</name>
	<ul spacing="normal">
	<li>Align title with document name</li>
	<li>Add id-sha-* algorithm examples #880</li>
	<li>Reference <xref target="RFC6234"/> and <xref target="RFC3174"/> in
	stead of FIPS-1</li>
	<li>Deprecate MD5</li>
	<li>Obsolete ADLER-32 but don't forbid it #828</li>
	<li>Update CRC32C value in IANA table #828</li>
	<li>Use when acting on resources (POST, PATCH) #853</li>
	<li>Added Relationship with SRI, draft Use Cases #868, #971</li>
	<li>Warn about the implications of <tt>Content-Location</tt></li>
	</ul>
	</section>
	</section>	</section>
	</back>	</back>

	<!-- ##markdown-source:
	H4sIAAAAAAAAA+19aXfbRpbo9/oVNfJ5x3ZCUqJ2Ke3uoTZLjrZosR0nOW2Q
	AClYJMAAoGTa8fyW+S3vl727VaGwUJYcO9PzTufkJBQJ1HLr1t2XZrOpsjAb
	Bpt6JxwEaab3wmDop8qPe5E3gq/9xOtnzTDI+s2rLBt3w7Tp05PNq8DzgyRt
	tpdUz8uCQZxMN3Wa+SrupvEwyIJ0Uy8tLi0oFY6TTZ0lkzRbXFjYWFhUXhJ4
	m7ozHg9DeDWMo1R7ka/PAm/YvAhHgbqNk+tBEk/Gm3r/4uJUXQdT+Mo3q1Qq
	zeCFf3rDOII1ToNUpSMvyf75+ySmeaNYjcNN/UsW9xoa/hNGfhBlDZ3GSZYE
	/RQ+TUfyIUvCHvzUi0djTz6M4GH4KYyGYRQ0NABj5I3HYTT4TambIJoEm0pr
	d31aZ9MxrOQVrBse08/xN/j2KkYYIuDSzfl5/P/toBUng3n4beSFw01tIdu8
	Hfzn7RL+CL95Se8qf28Yplna4h/nO/BTeBOk86eTLoBv3h0Ah02CcZy/Ogiz
	q0m3BXuS2el/zeB9FkQpAn5+6HWDYTpfPFTF7zXDNJ0ETXoEUKH4iPIm2VWc
	ACiaMK0GaAHgz1r6NB4OQ/qGMegs7gZJFjvfwzY29UXgjfA4w8wbAowP4H+h
	F+nn8U2QRHgA9GjAUEribjjG9/9zgF/gfujnXjyJMsQ7fH1aWMkhrMRL/Eng
	LOVw0vNS92tayfYwnvj9ISClO+UQnx3To63F5daaM7OK4mQEeHtDeHC2t91e
	WmzLx6X22rL5dmNlQT4ury6vy8eVxSXzwGr+cW15YQU/7p0c7hwcP9/E79bX
	Nhb51412m0bScAbpeOhNBe1UGPVLS8Ebt2nfWqx5a77dasO3p52L7X2aZ2Vt
	fQO+OD5pHu2s0Der7ZU2f3O+35FvNpbhm/OD58edi8uz3XMAeXOnVaALoyBN
	vUHQTMNB5GWTBG6l1pfHB695EUJnLq4CfQ53ZBjQb/p8HPTCvtCBhn4JqAUf
	9KJu6lX9Mh7q8yDTsEt+emOdxrKop3N8gnFPxkFk7x5sG8jSpm5vbKw1FxCS
	xwfnF+sLC82lxcKKDgCFYn/SwwVoRFS6WPrHYApI2ruK4mE8mBKBymCOvQCw
	3xvq0x8P4M1+4gEBgXcngj01KzumrcErB1EKU06yQMd9fY4UDNCLSV8+UUNf
	ts5beicA3MvwHuDD20iTkl7gbAtIaZu3BRvxkkGQ5bc+uhmOJ920FQHhaA3i
	m3n8gN/MHwYDrzedPz+lr1KEvYfPGkLM4GmN/T4MvH102VxfWl1YXS/AC7BE
	v5wMIwBDF04RINbDq0nH5mWZ17tOZ4Fi20uiYBAG+igYAu3WlxFgLhx4Bts+
	j/vZLVxCvRsNgOwGCRJSC7Lizteb7cXmUrt287e3t61rIHlAdIhg3kyAvIX+
	PO8ESeRBZ/usubiwuNBcaC8Xtgbo3mzrEM5En195I9he3Vaa8n9Dap639GEA
	CCA0K9/uQZSEXkPvJV4kZ1d9+QLoVDCFzZbePfaiqQcQsJgBJzQsAgwA5I3j
	JPgBHhp5aXCtD71unHhZnIRB6jxQAB5tu7mwUgu8YAwryVqh10sIePj4PECJ
	MEI1m03tdQHhgVEqdXEFgALeOCEs9YM+nFpKJEb3SYqA++JlOp2MYQ0Z7BaE
	hARWLowkbeGdVdsxfB9lTZE/6E3dA07QDfQkDXy6+3jx8vfhQtAsQnAA/WgI
	Hu8MtvAlgwHfBIoFw7BA0lKvPFhVaXV4Vel7dxZ3fLgMIGvgZQoAh2A4IBaP
	U4XTJWYAmKcPfwFKpLSeJOgF4Q1iO64MHoNbiRQdCZMskuHZKsPcSlpIoknY
	smSqvGD5m9iGHY0OdBT6/jBQ6lGBECpFUPFjGDyKzfHS0KPAA4ENdjpOQNrq
	ZfQlYJdXhKqcCmCzKsNWv7oCQu2eIdw4uPmAWFEKsEkAkt0guw3gKQDhOA5J
	HhvGt0GigZEFieoHzGJgeFzHGG474DwgW+9KA4+/2D7VvasASNFkRM9cHJ4j
	oGMkuB8//gP+fIYsdnl59dMnOkEY5Cb0A5WCyOZsRPYIy27pfZgfbl+D14lI
	3cSbBs/6xTdwINiRGoajEH+cZOEQf+oGPQ/QRIcZ0ph47P0+IfqJAPRyaZi3
	SGcXR8MpQBLvvMKnSHAjlgDYxVwU4BzZFRZACgQVAAiLvQmGGseAl3pXXhjB
	LypFBoNomr8PB3MQWcA73+MC4XiILo7jNA27vB/AXkUHD3BNJmNeQ0dONofI
	CEiYB/xmVAB0jkp4CZxjhr88VzWY4EZpTJTlARMJ6UrzKoTWyLsOaI9x2IMP
	3XiSgQh+i28BxQJgAuRpgcF7bzQe0p2FNaW0NXwo9FXfmwwzmYQ4Gozrh94g
	ilPcfy+B/YP2kGbBSMMEyMMB8SpX05DD7DYWelcHEN47bq2l9sIkJfWDr419
	uqFvr0LE6l6W4hbggZtgClhlnnzy8eO5LHa1tYxnKyLjp09PWwp+iiO/UaJv
	pftanqPuYWeadZAgAQWdaTTtXkg9gMm/QZbnWwDnN/MG5HwYT8idKpAMD6lf
	PAFBh1nHLTyPlzZiGQvpdxKPNEpG+ANobnAffUYQNYJzC/FQkwCuVZrRtXeR
	W92ffAKFjpPgnoT0B6DzARAVM1wTR/r0Ced79EjvmNnOrZxYWgYCzvzmI4j6
	IE7Ft+km0Gd9HNyaDdEakD3AZgLNahgvOAHNBD4zuyPMC2XLIG/AygRTRHMH
	gvekyNeeNuTB4rk7zzv87mkDJ5UXbhEkDAZ87L48E/CyCUItqKAoTPM1T0UR
	wIt4J7KaXaXwa9DEmwTy4qBpjh3XcV74yWKE3aeosrC0poHNMGZ640LnUL5z
	4MPo2SwuEFkIvAKUNdVouoBjFAqDRFifVXcjeqoVYYL3tFiU2nLgmjGakwgw
	K+whL4GpEKDOj+5PsoryImA8WcadgoxIbXXLwvP6+NEbDoDhZVcjBLLsKdVX
	Xgo32/yEa3CPlegnE0OyTgxClB8JEMAJgEYQF0cy2J/gDQBOkAlFhdsDJ9EL
	xpk+Ae51Ewa3eHeCgozJYyMDhuvqXquy2FdkSi3QKyOyYwC3iFNkG7gPxJZ8
	K7h2kLp7kyHLc0LIiQjB6GE0BgaTBPirL3xcuSyYJFJnvBCtUIDjcm9lOCv5
	gLDAogQOnhOYFpwcSoiwWNqUUFAmT2ZJsEFHBJkkwKYBhnqf96Tyk6Pp+BiC
	xMAt0HP4pO7kj1mQFQyDc+YEp/oJUD0FeAjXENTH9KqJ8GvaiZrmQeJCwIaG
	SIdFyKULDRjAXEf0AVqZBTdiDajzPvEjfMfyakDlMqBTYUD28K0Q5od9ErYt
	dtt9Fa8wyzF4KvSjUSkI32BZuLScl93ydyCBkRQhZ8DrKryvu1NkL2GqkASF
	AG9GibdFGvn2gSQexjNoD1hnFCwDRkf2rogGDs8mtqWqzAH2vAcwGiEDrPLx
	Bu3xrUM27ly8qi7+yUw28xRZoWwMRNEsJ6r26gHuTwKFttoJokh3SqLilK5t
	zQVG6BDiBX4dT1FFmUaXZJotjyTP4mYFG82wJd2GRNAUBXykcuHgKgN8u/US
	OihaKv4Gn8vIhBhd0me14AywRtRJ0HaNKxyB5DjGKyLmqm5gSS6JD+UVCVpa
	yYqlIpqARUmS6kGkCr1hGUgFmayhjAx3hjwBqJLIWU9Y/jGQbJcQDRCqgu+I
	FkW4GiyuocID0jZaRPrf1ogYMlyZn701V95DcUpZDQOBFrzHfabaKuZABj+/
	SJUr58Npgy9mPla+YlfDh4GDEEXK+4GBaCDIf2YWDesbAZpVbQEPggQat2uG
	dUwM+Zpza0N5UmZVoWV2Och2o17sw7G9pQtvv76YjoO3ho7JsPrCyNcAQT2A
	5UQ5co68KWDADXwQaV7lBNwlAXRtooLB4BagLKpUzcLp6sGq6wxHup4l8FKn
	wFQUWkBqhyAlw2wstw/gayJ/AK3qEqWm9cWICcrR/0jPMYaUUZB5SJcaVlvy
	2UGic5s6uqVgUgRoFivXBDO+InqCd1ZUcCO+4Su3V6CcaBIT6La3NFJ5kRAb
	LG4cCVzO7Wx4ra3NnwTMydB3rV24sIqhCiEwSRUzYbzMZMHAkS33dUBfQ5iN
	Op26zoGKMSq3HqB9FkUr40Vge234Qf4kG1F44/WmLFWesKaGK7Oa38dHRf1N
	qV/EnfKblTEJ5as3zXzjiqU1EqcCjuYNUzSX29HwGuo5YHEZ8tk5GtT+WSD1
	c4VzB5ozREG/x/Kx4BFezyi+Zd49YVMxEL+p2QCTLBJaRmS2aiCO0dGnAUwG
	AMwV9bsYp76TcSq1+34coGUM9nCFQ13FtxEv0U4u6gG8mcOZbj6RZJgxYxAp
	PGU8KXjSAVQYEdNLEYmQFg+BxpB0GfMAaBH0xExFXkwxN49itNjGoxEag/B7
	kd9TQ9JGMCaakVCKElnUSq1MgNge9eQWtqNuGeDw5PBpmaw0NOg5V3hecAnd
	t7T7Vpldsxyaku0DUBj0VzpB3BToKygXCctC6x9sPAtHDGRELeVA2nPk0jLB
	E9rUDSJADHQBEb6SmGEFE9CQYsWWSqTBYQ/tYrn9LezDHiJUn8kFiUcNP+Zn
	GTJzjcT3FScKEDL/goi0xWcQNH3ioeOYnoAXnAPuoWUXMdcDUjqY4JGyHU7V
	YNPs+9koKYjW/JPfdJbOK9zjybkxhH78+LeKMQUVdvh+plCLC7mDz+JdKphR
	nqqZOi1e8G4AWiKQvCFQXsNWepOEWCRRnPwq48roTqH7W2gE0YYeXJcEsAql
	PtFujVcEkQyQgJQqtmAdx5nxYG6jwEgnmJI0dg187pZs6nNHl+cXcw3+vz4+
	oc9nuz9dHpzt7uDn8/3O4aH9oOSJ8/2Ty8Od/FP+5vbJ0dHu8Q6/DN/qwldq
	7qjz8xzTs7mT04uDk+PO4Vw9wFhGdsmKh/pT2kvCLgN5a/v0//43iK0fP/4H
	YMJiu70Bx8p/rLfXluEPlDYauUWe/0Q2r0AsAFiS0j4cws0ZI79OibDyZURp
	ByD53S8Imd829d+6vXF7+e/yBW648KWBWeFLgln1m8rLDMSar2qmsdAsfF+C
	dHG9nZ8Lfxu4O1/+7R8YMqOb7fV//L1ib52khISB7kwGzH/01vGea8H5RQIk
	fiNQT8a+x1oe3VCMkfhNFH2gDsOJL8MlkyEG/Wyf6Sc9L0lCwF2gqiC/RE8b
	+nBPP6E19YPAZ9slPInfwvOHe08rlnu7SjbDEvEHLh1KHAAZf3Lut4T29v84
	vzi73EYZaae5d7B7uMPOpY3lNqAOCkkkxkx1OgXq8J6dgF6CDGFTbcVAhDzA
	pq0p3MJz1KmANjT0TkgTeAnQeKIeKFjim4fo1Gc7mGPq1XNF+oO3ZgYHx59q
	jB/Vr608ij8BWIDoDOA3c+2EEN5161Tx1unCrfv40coMsw+Bjy4eEnMnyyHG
	D5Tu7y8SNvMbjLNf0R+Z+InqRoP2WLEnGZbtX2HiADNfxpOgNWg1OCygAWgD
	XKKHGFNUAazHt6K7GucVsFtrWqPAEqD5BWsqSk2vjCEgn594BbumyiOEZD9N
	AVOYR1Pom29WPJde0an1kh4see6pIAyLm8YxOmfPg2EdTzI0aIrBwHVIsk5h
	F6xwQcBnGFfxV7JzNRTZMuCc55j7zZGbEwmmATUJW2K4wElImTN2ntwaOVMD
	3XSUY94NCi730NzVHRx4xqA1WrQVKUoTIqMk0aHk+yCjKagWJZmBD6Oy6lx/
	KBivCWxianFNbIgXaAobgWBF6GcMgFYXcIypgod15hU8Z1LmyCXr9bIJcPqy
	xFiy8VSsiWSvQwepeptTrrfl15ZaixT7VCaXKPSwHSzwelebwC1JtDD2KVxX
	deEytnuNniptNVMxEjqS+w8wLCMcebLfFijuW1enWWottVZmrbRBAFY6N59h
	lEIvRsHpRsLX5A7htTDXakyxFWy0zNeEwxg1I47E9ipaOcDhv/7rvyg2xwTX
	ody0u6kf//qYKeNtwoGpGtQd0mUpaLAUVLOpf4VpgCI0V9qLzzZ/Pup4o5X2
	iw/z7046Fxer8x9u9pPDl4OTny+e703b/urzF+HJ/kV89fvy9PT78eB6+aa/
	6G2nOMj07M1Jdrt+9O76aC28XZu+mX91PR6PjpaXL5Z+Hzx7tokrFvR28QDD
	Y12kbrDT31gfkJ5g5NiVtfsYZFYVHM4NQjXk1tGRrUURYxaMFo1u69wQSLJz
	Ph6u6CYeUigOCHKsPoakCZFOHOFdSWJcJtlBlJmBzFDCh71bT4SE2wD0yMRd
	nWBsGvSaYtRkdfkrn/LiyuqzTX95aeWn+PvoxzffDw57l/vR2vOfsp/WFq/C
	rZedwe/xYfomenMaXjw/vX622firEaSDfv1wjMEzGsRKDboM+RuiKYV/gCRt
	g8ScMPGm9RF3A9BrQngU9Er03A7hjOGpKQ2WBhkqlKEoLRw/4NGJi/WePI+p
	sGbfxiQAfowxti3ssR2NZAUTbmEWRMgNRzghZlLydnKoDmvSMgBbHxw3oaLN
	MioPXAN6ES+UuzJ4uHwz3LeC91feJGVXNCJUR0LPBByoOhtrAOI8UCR1HbFs
	C2RXjBSBcyZ5JIdYaCt3rcHXBX6SkRSxneIwtyGcpJxtmNVZwIUmpBzyAtMZ
	Z1EqMU1oJiDpEo0SjeoAuMMu2gKTAYdhsWAhNmcZxYRo5OxrpWS1alkW7nrE
	Df+u1+2FzhVEhH8JHo4qehJ8xoJXhEidFa8YtwBrQrsYQdjrUeQ9QToA8tkr
	ej9zCwTcqNxFWzA4y91yzVEejcQcsuRiQock4Gnsp9YJtb/b2aG4pSHzeKS7
	7qAY0uW4B+bk6t8CZObYg4ruZaL7Edvl5XmOqMcNizBthtHs48iNuxhKr5vi
	R81xy4HkIgdHxYCPw7GG2zBhHabO32CNuQ2Voh8BSJeNIkFMEJ+26E4zQ1Hg
	4Ci80rMyHFoHoxlBNRJ+hPeUI/s4ottLQd3LGAujuNZGeUs2YvJxi6xVspNS
	8JwORuNsqjDLBs2fjHRkXmqGkZMqIH7Cwl1iKe2z4qSqE9L0/7Q4yVLiPWVE
	DNC5S0r8FjKiA+p/C4j/fwqItUf8b+nw39Lh56RDXSMdqj8lHeqqdKiq0mGB
	/D9YNCy8/fXkwkeP9CUhgysZwoI4yHTbBJlaWeXjo1mRqcKZGQoFjgq8YRiL
	oOjptDZ8VTn+bzbbsQuZUnicKJ2a4eV0yeHAMQkcP8UIX8feW2yQDcUyiDY8
	Kx9IfL3JZqifywYv4WToZqtESolx2WDqLP8ZewqtwNzAqOiwXwfEojUTgThJ
	8/AngiEG8pbwpB4m+YmUTOVamwUDPLKmsSXiOfOMGFqXr9GkTVibo29P6t5L
	mSXH263VDc23jxbhWSeuREIi86lBHQysBhUInYQYuUZCN31AnIOH0AFMMQdG
	2KuNjJsBOLFAA5lD76VJuvDjKCBtIjHe+zolgvdJpEaxGlAQD4TvFwKSTOh2
	MfqoqvWslfMlDkgOzzCvU2IdZwxlbyOrLSVgyOUQBzoDsBb9i+IcRfe8pdxc
	G1cpMZe114xpaA3OjL0MI2vFkaDMXa0ZyN7D3NlQHYAYIexCya8lzCnDlay8
	tAsD0/z+YtpjBoC8Y1d61q5mRV0KhtCanWvAxLsc915GEQT5mdXHPz66KznA
	6lYlEs1YqdnrmN4HFWn7asZlKZ2FBbMNICf9IMxSUUDQ0V/RnSzw7P0aTlvK
	yX6CZ5h9k0JJ5AyO2LCrJogwxi5yV/gCQMwNX8BQbwqsJ/5tXWPsY3PDLasx
	enA2FUFCubGU9p7PCH6s99o4cYdpULbKdEHzV/WmGRRIaqcxm0pzoUYEqlsK
	jxuG1wFnsVDYPmakiU1CLm0cOXmPaRr3QhL+SNtwmJW+PDuQJdXe2IZkPhWw
	rbBru4Uibjx4/fW051tso3pyyP/7M+J+Z7jpkvx8PXue6ChVtVtPbkpbR8F+
	SJIuZ7mi2cVcRIn/LXsmkUJJAovBptadTkdaJclVnr4KJXvZgDwxFM1aEpWV
	kwmULLVXLpF1N08dwwbqQaMwy8dTbB/E6DGXizIJD943GSJNJraUfcTyfuDn
	6R1AGcTjh1zBoxDWuBcPdZAkGGTaLwRB4155A36rWPeFjgE5k92JcshBHfyY
	sEgIaPAez8NEfyUFbY68dBQHmFEErFH6mKqWo0thO7zAysIB+F6dlknmuiSa
	SSZmh2LT6aLBwzWBfB0HaNEoBbKExI5U3JvtmY5YXbFceWkP8A0mb4gD/wZu
	022AsmEBXihAAlKMQNnkkCu+NGTKXUCwtxc4cieFEfDhtlEwhgHIWzJSgtYf
	fJJ/oojN/BesjkMaK+8SNrEggcBzJIz10ISKhSnmKA6V7ad1VrLyyWxa60h7
	xm9o/lhq5I8tNDDI9n06GT1bqCsXUBmx7uc7ByVrCPDfYnJWOXOSayc5iXUf
	Hzk44aYweUCcfYy6SMKAU25rTGR8+jVFE0xaGdrInEQ6pFuiEmKciF2lk79l
	7Nl9r5fFSR5jnBUygE3oaaMUJayjIPDL17ucJ47aH5AYsotg+mMfU2jR2IFC
	SEghpWj5cVeYWjnTyYcj7nXQOe4UMuPUAzLjTGLVPTLjgBjmlihnXQL9fFkK
	6ReJcRRpa1ks2bWo8AHubZLZWCxrI1G7aI7MT4VChY1yLJIop+GZiF2fDd6G
	7+H9D9kyVTwV5g88SceFKazNzmBv6VyH+OYc4WE6CemOEixHyK4MbpEoy0qT
	E4Yo7rBiVQBiyamTXzlDxlOeT4HwCeFAmE1kBKa3lL3an0QS4CsKb1CEAfD9
	UGLyyV8n5W6Af2LSfhOoUzhCTwuzZky4d77jkjjs/nKWovKlNAwsyeKGZyHs
	PwdaMX8zp3KEwuLLMlrSMKCCD32neAXLNGEC2hzvA2PxAPAgXR1RQHCJopC7
	iWQ1428qmB/vd+I7KO+htOXPSQ6UBWiEej9vEpTkvIAH32qYHc2GJr0N7eSG
	2XGVKpsFzSWqpAIBDuUASiyAxoFD+0lu3OIe3gCzCzOnjERDdydiJ8NI2G6g
	ckHSxqajzOaiVJDhyf1Q9FhQfhJSJC5jVBRuHpsspkLyClHTU4w1zawvbZLm
	cCpTCPQpcr0S92aUPSdXcSrlFAACN2E8SU08ng17b1B+GKB+IskOdQISChD2
	EQqDYoXtBqWwkPIRAAVQgrKZZhKSbxXRYgaXdxMDXZlEPqLLWHDP40olqClr
	MllQ+C8WgcAxeCEs5LLLFsPZm2RvLxICdsgUKgxSckymgvfoksyNYGKopJp/
	FfKp9yYJzjPidDV3PBNIQbxsSHW1EHnhbQACfJwgIQFIchgxW7AmIdNvPCER
	1YvXSDmWS75IhgTAldsJ094kNb7DSoIk0szPXNqClGC1XsPfH5wDroxJqVDE
	jSzhIUnS7HVxJM/l1iqunSPrF1fp4hrDOSavTIa+oeyF+GvAZSxfpZRuFuNg
	N3n+vH4Gr5GkZwag4QJaV5TkRlHfbNRrmY16NZNKOLDWlUvxIIqOuoCWMH2K
	az2no9ysMUjb42MBKh5bLJUyY82c+jeZThRRxbhpKA4YOMEobdgXT5HMpnSd
	zNuTCGlv4ETxOs+7lJof9+03nDNYuWIN3N4OWdxp6ZvIAa4oDz3/srJZfOnM
	qAtP0qebmjytQQKfreUxAcaZTK3tEX/i4GyhiZ18NE2x0JSIi3XSqEaaH2Re
	OKwCWmx3SASDW/ar1NwGNkuyMEnbRxUzoUUIfo69qUIrduQGMsvr8DwfM59q
	4SbL66DJIHHkEqZe4kuWonnWFPDqJjGQwHgM22Y4guYV3HhSGYiMaFSB1ArT
	RDoOdi/28MCMB7JpHIvnOyeyJotVMqGYpwsiGaq8eRK9OBDKLLmBa7wOOL+S
	oBSScDgEVZrzxnPwKlsjIMPLzEnYRryVHUQuSUvtOssHoioHkk4GYtyFEWC8
	iDRU574V8BsWW7gfrT+NF8CLEYJItzx1z1lxh3h+kW+KwL2zwrT1JGKdAMqB
	Id2HU3mtFSeVQiGW+RaWjQx9zKIE2lxKoVdkHUbQUWq8ZQB5mEIl4t8oDMg1
	LQbB+gqb9MTzZtzfQXQTJjFVc+XACckp0+fmiZIm+/GRefcTme6J+RwZG2MH
	CNAxAPqUxVpKXwcGDSocvdekcms80qdyQomIMgHVkijWqsvLk7nJ2JIXWxf5
	lFdQYHERD59WOqtgB8pkADiFNSkxa/c6JL2479ZNm5Ftj2O7WhmGyelBEJE6
	7cj3RpQdeagQgpCnMzhtLqJJgkWxXAq7zrFGWmpSOJyYCHuAeaJ6AxRr0C+a
	Yy+7ajizkEJP0iiIUMBfOKHbKZqDGtGkawqfmkADRSRRnMysIRmtDc4wHEje
	l2TPs4fF5swXcn8QmZU95jzJ3obiSO0x5aVO3T6usGf3iQyvkmmvnxQEaRcX
	1cwM+afsc9oFDTCLm7uuDbPmhI0Ub5Jq78Y2EHZ9JxueaweWlHIyv8JpAWEB
	UkWBjzaqkQKEkvg93IK5ssdujTyhTvynQrMxA1IkebndtKgxBgjacng2+OQq
	HpOdpqY+3u4N+824ZE5+56T4H0IrqPoISlc1ZF6KfMq6ND2dp6aV6yN5jotS
	6sXhEU9AfQ58KjJJdd5gKT6nmPc51wpuy9Eh5ehh1h1qrKA/Es40dJD1WrRq
	SeGDAweiFBhLtggpaeBiLBUqzz3GRgt29j2zumlK+pAqgLiBtR+xPoBx3dqy
	DLZiALr9MnIEAOXGSlRHHD7r1O1U9nUkND4rF0ZzqA3RNMEwHpeUcC/Bo7oX
	UGWp3CqcDK2QRgvN4gHHGHEmsy3aWXS9WNppXKB5ZhoFqFCmPNerMWGvv+T1
	nn8ThdApTS2lKOnakTFCSh65RRxsNUA2uhSDxhy2hbp+PfmWPFXfUSyLRaUo
	Lpdr0NNQgGW93N9NTgKsMEIxybi9CpliN0ctZTHGDwRsS59EQR7CY+MUufCl
	FCnBOUcOu/hsPRBSSjneDCtSoAljOC1Zo2YmldrwapMHyPn7hdoxTsC/LTFD
	NxD0xk4JCDnnrkDDcGkuvzJ7RT2Sp8axaKB5YL6R9A1PJYlKWd6AohIzQrqI
	+S0sRgJwORxaU9M67rWQMZVbRyTcUPdBhiCtqxQ51yBTDt4D0YhcOzhJGmgg
	TG1UTCkSJ49WFcYLiDcZmWRqoZd0GOQdt+GwWDMv4BImnymhiAXfijceHatc
	PqeLUnSAxYdwBVU7GlvOTFmvCmabkD3X69UqRyL1KXqC4g9ssQzlVq6lOYql
	eXLaQGVwSZDtBaDUh3Feo4vDuSK0ATNLpgpjkQSz5AU3TOC7lsB3uY5FchAY
	UoVOiwb6TFOq6dDI5YLCsTulN8z0GIQPdAnVETaw4t9KYrVwHb1e6EvospjY
	+5NhobCMsT/Ab2Hm7Dk0JUWM8/cHWb4kNJddz31XLCaxT4yfYeZsyFOV7Vjg
	FnbF4qRPHpwpLngwlCow1WpD+bok+vUxjN30J/ZSKFqbESVLNQEN8SlJRCuc
	q+pIROwbkHCvnPbkF7bEHy9EB5CeKmqLpY2UfalVKlUX5NpwwjOMgcxwH9HM
	I67lFZKgRZctp8Ws4LHq4CfxmCQCmUJVcnorWza6cS1vyy3jtWt2yJwpOkmx
	DXDv+5kknNkyi7sAssQNvHaKGHbzYryliQwZTHWFdjYMr5s6pYFUcYIwoudN
	xakT65KQwjhcS5FFunsdFrus8UwyRYBPrX/V5MiLFD1lNxjuPS8bxm4vJw1H
	sbmhvrQhC7cSZFsPOVgjm1YwOYrz8zjMJQoGwpzSfLMlK8FRkFwP3WI4wsW0
	YcTq48d/YBMQkCtHKaiG7F0Pe8GnT270r6WTXRtZbxLikPYHnI8hqqDUlmfe
	S2HDrAKwB1j03xsAOqoAxnFpXyLqrGBzQ5CSEIQOWMyl79HVNHewho7RwYom
	Dzy+EnSOV/wlciwW2F7BacArFeCY7FxJGnO1ASSGedFOQ4sCeRP1Cg9EEoBN
	Q5viV3m0kkfl6TFVyM2ek7QhN1eF8onKh/r8zcFpHr5vlQoENtZfQhwm76Hx
	oNQsijBXLBBwu1CschIYqczHrFBXWoup4dVwFludXxAVcz2MP4C2PlcWBzf1
	4EM4npNYMX1CXNDmzQnDNdlgZjdJMERaiaEFMTlD0QAWjtBjPyL1Ko9P0F6Q
	thfXB72RUzaTeU1etwZuAnk01tdF9iE0K15nMbLZgkQ3BodI/OBabs7wkiEp
	6lCeaCJ5YWGNwI9HUXB4igMfPwFVcKM29ByrxtmcmkRDrLyFg3KNQCeBcoyp
	amjVZrTPPS8dcTmx4c24mFQx+8Xpy1AfaWIMXP3wPU5RHV44FAJ3bXVjVUrE
	gt7Chd+7ptsCiRmlWmAk1PWHwXuR+TB0WWo91yzFugMp9ON+jrAvivgAGOVW
	VpsGVkhRs4X0A1/BFoGexVlo1d0qK2AO9ZAISYFrqewYPAvTGdJYySjixRLF
	zdxQRQZq2uK0Lf6O6JUTAJTXznacEzb85sZ2E1Im0e/aZmNRlhxa9/My2oSb
	+LI4qzkcAqQIm7jH+vpNSFeButCUdyWCidV9rN6DVWyIq3hT8nR45NWxGSey
	QY5mTFlj/nwGyytKU666bEVKIF2AfeusaAKyxNGgkByIUTGOBYkEHzdEoJJN
	2KpaBfy4YH9CYVDMrXRlyPEX30awEJ/sDtZyizK0ORfarS32i1PzDV1dbLfx
	hooMVcFTYPF5zxhjr2ZKyyM3nMzLnvjK2DQi4eMSwGVvhwsdF2hxJAUD3fKo
	AgLWu7tTuTXYFwaenK+1AJv8AbEg5nl0QvecxLoa466jyFssc8IYqNqy4Fyr
	WAyRAiOS6rTlwLhUDO8MJOVMWPZ9kiUJABxNyD0NP+cPc9ANcdjwQ+DIj8ZL
	kNf+Tq9DzjN1pjLBxOQnNrmLNUYMts1huIYN5nT8SyCk34gFwtXT6aUcJcVg
	MStN9hFT76JTKXckcTWHYxQj3EAIODoK90PZ/JpZp3jd0O44tz9FJha8z/SF
	qQNwaoKdn+C4T2sGnjpBEk+cQmdPq8lO7HXtBkAINpX6o1n3zx8zPt/nnz/U
	H+4C7T9/SHACf677xzrqK7/88Y3WWSqfJetEP6YXIbn7o66ZCeG66+srrLOQ
	/pPvvTjmrL4ndUPjmHV9TspjFluj3LFId8zSYv/smKVty95N4VMfPjsxYJUO
	NtUJ7Dor8PxTY34DXGIvnJHH6KLdU6gzNxho/OfluZx25AEgKGcmgTH+RsHt
	vQOrlG2uARLL39yGhqEXedSQz0uRPVGwGrdyFTusWeD83ymCVgoakBJig4UD
	7qzCCguOWN4WkSI0p16YLHjszkJtviLqQ5QTzZSjzdyKJAWLLFAyXTwTnX+h
	y7/V/lN5itCvWAXRpWJ/uOFItQSNUdWNP5J78hVXSuNJYH8+J0dMwAeELJaT
	xF+dELDSEn+R7rBwg36R9rG/lcoXt+xEiyurd0yEv36FiUb+SvHNPO5DJsO2
	oM5EnBx0c3efUGPML0T1/pL3Hf1NlogNdu8Di88skdt7/olFUqwxL7LQRNSs
	E7v/FtdpAVy3Ykn0uGPFrpKXK//UCneOKnii6QXDuGUB5VnhIz5cDzCcnq0L
	XzK9lBD9MwvwfLSs3XVinZ3D3bOl2Velis3Ydbl+Nq6FetdsXOD1XpMRO0at
	Z2NxFdkaloEGDfO97tTO/Q1I4cdN/WgmEeeGts/mDiT1pcSA5ji8ygKA+ePn
	BV1hVzkNfslatOGZM9ihX5jnPhI1T6TKEzntp7xM3Z9DEmd0/2i9v8pGw7+b
	tFR0ujO3xkiOWHz1di7LQd2Q5PcZiOvq73ruovAstTCyeJUaSyD1cC/qZNVM
	K2UnctLVXXmr0vMsL11fD4y/Gxs5pv10sa1nLqh1p+rXX5J+D0NQukETt9w0
	WPvrb9ikNRwGBaZvYkU5Z72hK0KB8sTKOsFuH75pdIQ7+vWXzwhBioWgX2fs
	5B6Cj9W4pMKA6XDbBSqOyqFV5EsN+Th/rvDVDjodsO5ffZE1055EjCA5WljD
	M9Z+p96jM5OeRY9RpaJz7DuVegKg7puWnI67mKMGnKbHaeBUiqNmNcZmgGmW
	6pItvBT8cBti4Q3Jgha3daHKXNdL8/iTF+cnx4Ax76i+xce5K+zaPbep5m7j
	ZOjPfXorO2fWAHh8uCe9fV1vru3ihf0iqL+0x1VkPKymhC34JBCEnPJs3JNa
	aU9NgTqqpM+Za07V6avgfdNUVSPvWovcLuwc9WwON/m9QIoPJKJ2iJHVXmFz
	eQWR08sLgT6KB4rtUL4kxOSPOREX8+/SOLfeU8iOic9HA5s5Zzbr1xXzwinn
	RTifbwPXtMUF1X6MeaL9OG7JIdmirxhLsllZhv35MIgG2dWmbm8oZQ9Om4Oj
	xFJgIMIlJODYnBRXmXTBU7MfcVMgJ3H7HhlrZMlXQgXKwyyQ1iuSNMrnYyKR
	U3M2ynp7uNAgp5ehm8cMV2g/s9xqt5bK1ajzkDwgknmRqGI8DgPprdtnboiF
	TRKxEvp5e2bx6pncpPSvOseim6tyvEtwvO09vb6lF9b1woJeX9fLbb20pleX
	8c+9PdXZ0qABbHf08rre3tHbG/jvypreWtQri2plQS929PaeXtyjZ+Cntu50
	9O6KXlhUMMLOht5d1kttvbum20s4Jv17HwTCBdvr6WDTnH4E93Y8yZqDD1Iu
	xNwqc8aBnx89Z7USweJoEn0TejWdx9gNnFehddxYI2+IBJa75+gSNkj9B7ak
	YosvxjcJpf3W5/y/6EQtFOkw8eJXIGOLoi7DmFueb3K7VGn0jkDXFufgrBNn
	CtNc4hOWq6NisE2zJA7ASfOMBTEml0rW52ft1pxVQnTIjViMkRPhANDnbeF0
	3zoJ0iWmqN5WaWstUyyQSFkCimSWEwPfzs3iJeLJ9Q7y6oZYZ5SKKtQh5/Pd
	ByBnhxxnZSJD4N5kjvqs3Vwrn545CAmCJgXDOa+L/FKlgOkpZV04+zapQAAd
	Pn7fJCnkjSjLeRdPMJ4EiLKEkrA/J4FB2gvG1+HyKz9MKVzbt53vFJmocrpT
	X1bT4u/iwqo+la3JDf0cSf4MIXeBqheaG/Pli95Z0VvLemtHry7CTcWLXoT6
	qW3Raa4MtSEuktlSpxe8PSgN8bMltMLrRylFxRQnET17lP4DPFni3fDu3Hnb
	KtWd7UKpWwiWa7ZHj35MklOxX08uUnSdAgamKg1ViiO/p4nl8HSRZhrvey4R
	rJZLOFYPGlfzwGtSc7j196d0cO7O76aai4AGJz9+RdGgfG/zAykcxxOOVZVj
	eIqL3OO+c4ZFOqX48opKUizBD0CCGw8L1Sgvzw6UDamYVRHQhNmaoyYfWIFE
	SnVUT5+enF/YHEI/TDj9C/bxdp57Pabzbwl9Cohnu0R5NdXYVKGan4iKeXWo
	mcsu1mZTOd8wYWnMQcyyALfeuuJoRfg0+ZdIYkrIXyt8ACS0Hf2LsPZzIsnH
	OR4emdq2NwqHwyAJK0oDLeSeaN3W2+QR8e+tvsgpbWoXkGrG17Di0MfVwh/Y
	9eg+y7eXgRhPpSYgIwfZybSpIoTYfxmlVHIF0U+MMh8fGQUaS2WZX4UR1pgG
	/GDEZWwy6UpnEqxsW3FmnsIcTX2NausDjO2p63dMlT9RcB5cuZfJD33GNF4i
	Zb1w5bUHhA5hdBtWnKhE2DnsNzXh7TaOYI86sDp3yJR7adhX6HL0w8wGfook
	LkNhmevmkK6MpjxPtjXl9Q5izi6LBkNpGsa6Oo4G8MWN58F2mHVjooJT+Bku
	2om7DI49DN5jlljNzKXyKOUkOHwhVU8QvLSQMdcDkIyPsRcmT3kVizw54ZVZ
	TkgtCUw0+bYJ/ytkP97RHJLiwJtkg/AGEZCEsEcVkUqBP8DcY0qWN8nnXtEs
	Z2VNtkth+p5rI3JKrttyXpz1MDXwZOOhxRKuBcmYgkklJnT/Pi2xbTEkrK1J
	U9rWDUNp6HvON+ZMym9STnC9RU9W1OzDI1WrXp3GUG2eKoXRbITy7PLJJjLZ
	y2wxNFuN8B5Ny8geh9DK66DeSOR8vWXuLiVE+pVfTVIu2mKNLJKKO0OVAFo2
	Iip7F6sp0VZ8MXGUBDx8GKaWS9yvkv0XikiOFezOZklnP84v/D5trx8Nt85f
	Rq8G724/rA7f7L56dzo/3FvZ39vo3uzure953Z3Bs807yuo/bJz7GOZcJsWp
	j1jiYlZJW/5KvDulS3Ec112JGpwvyepk9mRhS1Jog0JosjIyoSm5e+GKYPV1
	SZu2RKFb4bcghbZqCtrmZKfuHtxTGXe0eeKGZFp26iObFK98ITP1hy+5GwXY
	/o9ejloMXl7b2f1p/G59f+vc+37+4mD06vuVF9vB5Kfg7Hq0cnw0fvHqzfOl
	q/PJ3uXXvAl3oT1RwFKwFSI9f/yhiDb1uG905/tdAEdmGmHsMaK3qyjbGi11
	gpoqWUT+HGEtmmIWmu31Bxpj/jxKzTaEPMTiQWuf/xwdfveuN9jaeXXcybo/
	X74+WFrbfvl8aXA2eX7Seed5O2fPxweXe6k/DcY/fU3sm0F9KxaXO9HRWc2c
	ESUcQmh9d90Yq6dGViFEJbJI6kgQKM6QvpUkfcmYadW0HitT1pxaioQqMWDY
	GuxLyKbBekmTSr9BW5qHnRtVR7WWVXa11wlsYZoXDpUqKjlONu4on10LTMN6
	lPVE6rd3wo1ELk7JZQn/2zR8fNjdIdgBodxmOodnKzTzVHSEWUK0YfAF/wCZ
	WGZiowu9YpMIVTEJZWx1zE03kX5bMbN1k1IzBq4PisnkWSito42l32a7bSVx
	NgxtElhZUqkzFhVnrLERzWpIEJrpjGWWPZ53XliSPTDVVRUT47yEkTbLwS5N
	I2ao1AW60419DkqxJvGyG11V3OhWHArv4b3/8vZU5Ee7Fxv8DMepwY+/UEjH
	bRguTBwiZwJ/sbaTW8csVGusxQCcsn4Ez32lXmFKsUNjfUGvbenFRb26rldX
	9Oo2/bun4JulDuwLf1pbg2/02iL9tAzfqLUdvdDRC0t3yoM7tspC7vXg3xHk
	DlETSjbbHtAo0bzZSpJL8u7Ldcv9cGxxBNI/VNWbeE9FvqxhzVqOcvLvskoV
	kLx4kEtI3WIK1dIrTAbJvHibN7KSddjcNKEYd+pPfzGBqLEHfDua8WeIxmfs
	6MuIoA8Uw2fv8EtveHEnu6R+JTVXVHSxLxcxZEjLgrLbuFRDuNzx0c1+/DeL
	/EtY5P8uHlnPBusY5zdpnul31/r+Vnfw5mjwuv2qu3j0rrP+4c2775Pz40F/
	tLO9u/v6aP33w1f9cT8+/nkh3R7vdz686b7DQRY2Xrfn1/Y73bUTf+WnfhYv
	/zSebKV73cuTJf+nZ38x792V27BdsLuQU/CswhLyTEK8eAYRsC/Qx0e1face
	wnHv2bjPJI3O6M2IBc1nhfkgYyZwIIIfB7fqgv6oDfUxK5/Z3rHooUZCQ54j
	wnV3zpqhD7J7NQZTVWd3ubjRamu5XOvnB8X9a20hMfS7kO46qUgZWCNFGj5Z
	n5q7HuX0JITlV9cz27PdjePr9E8TuvtQQIZZNp3BFEe71373ZO088TcOD06C
	QT87WfC2Xn//8vTi5Ye1+e3z/SBdfLO4NugtMwl0MUQLhtT5zO9LB7+S/5wA
	Wvae51/Wb37y8hwQ8uLC/+nydrR4Ei1fr1+8uAyvnx+3u/35nXT91enr5ThY
	uNo4oM0DeXJd8PhnDTjU3f6NnLiYSP1aqrJTaPNpoClpgEJPatpyfn2SQpdK
	/auRlHt1QU3j8o0u79rL7ojbyUqES32GcKmzem1FOtObemXSXaqOougCRVFv
	/01JvjElqd/K9PXB852L45WXST+ehumPw9eDsx8v9/eP0qWV8+Nsur2Ufjj/
	0IbtrsNWagkOEwvGS9wj50r7TDTKNASfaK+sbiwtrq0tbvAjUj8KH8yHfQht
	KYdIUiqcaTwKz1LjUknxMY1qvcgbxgOqqx1LPJqlJXkBw3JbVKn1z/bIPDRO
	bjTNY0eZiN1Sv3XPgvpXN6mx6fd4Lm85xIPTTJw8MCmStIRFksrlMGvNEkVr
	BFUiN24siWyr6QD7eTqmZ9Ax5dCxzxku6kjwrGCLYudXG41XQ6M+J1zVkBE6
	nxzHvoyWlE/wX5SuPOqHA16lJTG0/S+gMffRx/5FxY4yacjjNj39tmh/eVu0
	ecRORT4MRLUcDGNs1Gxc51gzisih/MxhMAizcETJsoBf7EekNNHaoKHy6+69
	8SohFVQUo5B4kZKnspiMMaPhNNoKrUYXBZg84SXhcMqs2VCNck9xfWDaPYdV
	7aXuKpu0G3GgVgIoG3lmX0rmTRvIZKMqMPD440eL0J8+Ue1Pxm1XpqCCxVwp
	Pb/lpWQN+7DdOjXcUKUYAC6ISAU+9TLgSdEe5rGNSaqiufKZtEuNVLm7nxD0
	9YU1Lhr3hZSTcynrG7J/BRLpJPwsU2+OPSz5f8fll15F399BBHZfby2cL77c
	W9xfC99dd16+uN5vn48WxltX8UK486Z38xIEjtcXF2/OO5YI5LferIGpAfcC
	4khgqo/IRM0jUx0dZBDlyMrvWNEE9nRv0sG3qkpAqB6wPF2sB0wM1SbAb0vV
	0E5katmbFBrC8VKAQFrsL9LQ6DHlVPK89YYkSLMv4JbiMdMMhK0Rx8UyqbIx
	gabtRo7wXLRMupPcx3vJt9CTAjN3RVp+subTiqTCJW/J46moYrYN9jQEQjJM
	3aL9JjFFUlvSe1TkK8dnWNqdJyFI7e65X5Nfo7n89tBvbATePqu/Fn8qcvLs
	jpj6b2IbNUjoSB69q0l0DfKUoOymydFX6wgMa++lP/grY/qlP5bov3Offo3o
	wwL992uZm2mwEty2eb267nqyiF+I4q/U2jq/I6j/a4T0G4bFQ2GWfhHx3RKe
	xXB7nLEbAIMP46TQH6EQLVTfpz7NQ0b/Hbf/Px+3X+pa9C8aue+ET55zB3jx
	4D1O9SG16T61iap5Jz7lJPTbxpKm6mvD9O8mcgrXfk7a4/E0IdaWDQKOMDYZ
	2GpOyMMcLu7Wm/45Oju72zc3337WXriDFvO5l8f46yj0X+ipK1NQ41m1Ry1S
	TRlH8lI9l1FeoBVkR3H/IkFt8oE3OWqK0qXMk3kBo0+zcIkQx/h/84Btbk6I
	tCaOqOFBXibY9K5Iy+hGvWC6w3BgK2VT9XSvKA7YSgY0szK4jCVJWKdhm41X
	53/+Btj6vxBFyef581HHG620X3yYf3fSubhYnf9ws58cvhyc/HzxfG/a9lef
	vwhP9i/iq9+Xp6ffjwfXyzf9RW87xUGmZ29Ostv1o3fXR2vh7dr0zfyr6/F4
	dLS8fLH0+xdhtIudZZwWlN6JKRIIpAIp0i8onKM4x/tybDnI3CT8K0X55fdC
	8U9sUrSZr6XMPykurfJA9MepIaGBbaPs4Fonb3uJV8CtaUHRlNxdUjkuAKl8
	hVtw0Z4oL+uk4jlAL6+th7/8/j3K3Cvv30uCU7FDtFuempmdQsbidFjWeaNT
	Htj0kP9B5cq+BUs4BA6VsVodO+2rVJz3TJwdu18hHaVmv5UofnOeAgBCF9FX
	bVNZVy03RCJ3wrhFmcyryrxq4qI8KgY2s0x2qvNmD6ICOlQsTDFwDMQwOujI
	3fjs42A7MTF500ksUYW+1yQ6TMgO/BWyFr4t+ZpZZOSeVoeSxcAZoWwzOLeU
	onpKVoBoGEpXsR4szLYemFBlU32krqQ5Jx+f81UQtYTL4JXKj2EKU5pL9twl
	zgmSorLulkVVt8JKBjcVKejzn4tNZDwvToaNZwPsLCdMlWSAZBLZ7s22j3G1
	kYHN6uK1YCFb901uaSKqd3aVUILz2y0sh3IusVpv8c6EVjo2pTsl7EFhqah1
	BND5xdnlNjax22nuHewe7pybMhH3ZI6mwGtTa7356s3Oqfcyml97Pdj3OtP1
	8Sh+17l+/io+e794ubd9tbfc7iymN6+/v/BOR9//qtwykp3ubWew9SpKDsKf
	gdqtbR0fTwNv6L88vDm73R1d7L96ffPiNrglVmeqvdKsr5fXdzd+P4mvf/89
	ufGzdD06eXH24njp5NXOZTx99X6rv3bdnWzsbJ3u4rtYwLUpk26e+/MwQ6d3
	c3x4/nt7NXg98VYmP5k58ucW1ra9m3c7p8uTpfmLSTSIL/dfnMy/+pAs9/BZ
	U7+U1vP8p0vzHes+Tb259iHd73RoXK71ySNvnry5fr7He5KqnPTD5k9Lw/0D
	ep7yEwD9j7grAhwAWXXxBLDcIYiTI/PLJ5ZVbJ8K0nOMERSNl9JKrr6NUizI
	xlm7dnzjWsuxkTtlEtvOfZBojMb2WygUEqeV9/hK9bC5zDjjziv8Brm8OVWF
	7PVw8bEJkp9XV6W9mIobPHipYeGcMd1ik9ckzeLYNLlADb/cIoCDfGhXahTi
	09fOBhAAmKXM01rqf5m6RkLTH9qtQmkkGBJ9aHZUhVMGKKwaW794UsXfNKiH
	LWe3uOtxQG4Akt3Ncu0qMVzAHAN2giOxPiC5CJcDoFJSV/IWB6CFRyA1MOip
	w5ZJy5iVmp2XNHHPyMhV1Ta0pqkaMXuF3VwHqTQmldb0xoPxC8ek5JYlAtZv
	Tx7VmiLz1iDEBKbw63scpT6trJgCxolLvWInUnzDMoKikWEQ3ggvcIZUdDk0
	UE9q5gRw3SnrV8FU01mawqiFHlQI0B+U0xAEJaS/zQyIadCvpsU3V1KGb2Y1
	m7Vo0JOuZSTU5s2mCAK+tcG7bXPdHmhl1P2hlEhF2DM2KQDibRsL8rrLMM30
	XFnNXHmcJUwMj7KdpkTeQrBPjHxdXg/LdZIiZnrqjULCBDHjWAkcy3OuLjew
	9CUKcT7IeyNv2NJbU30TJtkkyFvWnWfJpIfA9G1s/91pi4os6xFrEGyRK+2j
	pfcmScYdtuA2RHn91EIN0WJd+JT9AK47QnoJ607vGmA/DPwBy6EgKnGHksB/
	NtcHgooO6mIj9zDNS5TCHJ70JXJ6DqToXfSia+oJ8yLo9/VRPJgMaZkdWP0k
	ATEKCB52exbKBgc3wDAUDZLNNRMI9sJ4Q5oEgQrqF5wQsQ+ZC/Ya2zpcxV6j
	0k3ZGi6PvOQaVUr88cobNWhdCVytn700vQ4j1kaOMOE0AmyghnqcY5EEN2GA
	1mZCm6OD7d1SHS9yDuJ2ERdfTIYhLAXkzN7VNVfVu3KaZtOroJdN+KpmcZFG
	NNirGZccr/al2BBt8jdjP8+AatQmMdUEqCggVOEN5VocpTsZYBd53O1ApyPY
	qiaywEVv/cTrZ6YqmdkyVVlm0AS0BX5ijGViqTLUpjoKYZtbIYjA44baSnDz
	24BvXRBVG+rIy2Ant/pHrHsbNdQLD3vwHGFectJQF0BIpvrUmwynDXWOPPAC
	C4zALy+wdC5AMexd4Z84/24SXutX4dBHCylg7jZqryyb12Gt5valYZT0e8/m
	4CIGUiiVdPID6y6mvTkNy0vSdOPuyh/3Tt3lIgdhodyWFaFjKpsFiqVBg3+U
	/RzjaXYVR0ussrudpQFV7E6M+IU45zoVlFCj/U7ZVm3S6k0mF3ru3FJZGVU2
	9rgDBVAf7i6omAQK0exPIlaCbAt0z/fGUhxM+tc7DeewLS03Uc28a/LVxOR5
	n0S2x1TRgE4Yl0yGgSRxKEB3NAkZOowaZYPkymHYbeguJX029DAeIOtT8H/9
	zPzVGgTZIXwMkidPFZBuI3H8kzSaJ/Tffzby9T6TYVsgk4PY/3STNAdTd4Pf
	gtHt8zLC0xYPC5Pg8zB569ZLUIt6MgfTs/60qX+Nfvk/yW8gwcpb9LBYhATE
	nPHCqytO+7SFztFxcR92B+Y0nw29Udf39PtN/f7z+2Kq9k+TZvPMDvOkZoUF
	yJVedaaC9Sl+G8brPq5el1+jx0pRzs6TOeP+1H/UKAp/FPzpc0/NSwcSo6Wp
	AQVqZ3/MNYoAefoU3Y/3Hxz7WFVH1Q8x9f+5PUmm9OwdOUfMGN8yHTy/YK+V
	2fRDEmy+5umhRl+z11rEhWef1gLsgYM0CuaAWf98RXDXbLn7+EE2+scwSt0/
	jx3j/ecM949V6eRpIXBFH5YhNWMpj/PMqc9lTT1WUgtBb6O+8gBujg4DUuRJ
	dmmGQdanHshd7KPAMOfU2rTZXqyVbNV3egvN1QHwOOmZ6VgtuWpaEAEjQt+U
	75OSSfVIHMvtLTURJvH9O9mCc/pia49Q8NnU6Txq/b6X+PMe9QkCyWA+jEgh
	C+bzthUw0hntGC0PZIT25yqDwkMmj5N2oAeTkOPXvG48KbSmNLOicOc0x3C6
	N36nd2F7MZruKKgnjLBjuxzIgyDdngXprzXBwjeeYGHjW0+wPmuCju9zYRo+
	wVG97a2lH7U3Vtcb+L+1NmLd0EvC/pTNMWTC/04q31GXbwkqhdcWFzbWCvuQ
	5UvHU9ZWteggIBQPqBcqG8SyKagviGImROG+u12btdsD0GrERF2up1b2Q7AO
	4lwQPaNDS4ui/dDAnCvfHO5HUNtYIqi1N3B67JQDSiXcROqZSQ+sL8Evxxjy
	Qf1AUK3CPjkUDihNc4sWH3prbfFhIFmdBRK59aHfNKZmivrnP5FC25q+xoVV
	57jQj9ZXVh62opXZK+rGsaFwuQfVeBts251H7ZXVNUHhkpUDflpezDd3fnZg
	PSeP2str6w9b6fJMdBI9uDj+0soyrorukz9h2h5UtgMgay8utp1RZhw3ghb3
	gtZ8VmY8i5a2NnFALc1h7g189EQa/rAJC79dKdxB+Gb1gfizNPu0TJ6vLRmN
	vO87vUM+NRRjkin350MWdp3an6hKheNgl/7IAJaVBXcTTh96AMXCw9Y9kwvn
	jbC4RdyjdpvPjTrxAv5/x2YcWX9ezAPfZSwL03Ks6tHu+Xnn+cHxczop67WU
	8JP8hsMe23gkVjCTJzw2DIi5nR1zqDbL1E1rm0PcQbpxhO+jjZaDNlPaxlrh
	WAxk8ore+MyqXBwZmTr5kXU/bxZVuYAw6TKSMaR3aG5IuFB7BbFJ9DCmBz/u
	MUWJHFuHMyjRRKqe8EAiP5PrO8ViijkOtXme8kjRUo9+n0fthQVEiF0uhm+M
	zU5h9AhQc8qdhaK8Oj6F/SPZYZZmmsQB0BcXC7fQYQQNfAHPVXZnqEmqJ2Mk
	9+2FjSb8F1QH/KO9ihoEflhr8Lj44+Lyw+A3U6jpMBdG9zVfAWuIxYMVvBEG
	8Z0jI1oj06P19YUCCuYdEamPoumaaGOqALZ7B6fnzXbhXgJOumSA+gI2lxYp
	1caPo8dkYu/iZQWCv764jpjJTZypqd+2cWxHDo7ZB8mVFEQahWI0MEY2CD7V
	TzDVr8F5A0+R5izxpklq4GxVULnGDByg/WLKpEG3sWs2vEPCEstKrzwMuLEC
	Mnq/rLjvRvfmZer/H/C73Dak7QAA


	</rfc>	</rfc>

End of changes. 231 change blocks.
	1514 lines changed or deleted	472 lines changed or added
This html diff was produced by rfcdiff 1.48.