Diff: rfc9457.original.xml

	rfc9457.original.xml	rfc9457.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.29 (Ruby 3.1.	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	4) -->	-ietf-httpapi-rfc7807bis-07" number="9457" submissionType="IETF" category="std"
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft	consensus="true" updates="" obsoletes="7807" tocInclude="true" sortRefs="true" s
	-ietf-httpapi-rfc7807bis-07" category="std" consensus="true" obsoletes="7807" to	ymRefs="true" xml:lang="en" version="3">
	cInclude="true" sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.17.1 -->
	<front>	<front>

	<title>Problem Details for HTTP APIs</title>	<title abbrev="Problem Details for HTTP APIs">Problem Details for HTTP APIs<
	<seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-rfc7807bis-07"/>	/title>
		<seriesInfo name="RFC" value="9457"/>
	<author initials="M." surname="Nottingham" fullname="Mark Nottingham">	<author initials="M." surname="Nottingham" fullname="Mark Nottingham">
	<organization/>	<organization/>
	<address>	<address>
	<postal>	<postal>
	<postalLine>Prahran</postalLine>	<postalLine>Prahran</postalLine>
	<postalLine>Australia</postalLine>	<postalLine>Australia</postalLine>
	</postal>	</postal>
	<email>mnot@mnot.net</email>	<email>mnot@mnot.net</email>
	<uri>https://www.mnot.net/</uri>	<uri>https://www.mnot.net/</uri>
	</address>	</address>

	skipping to change at line 43 ¶	skipping to change at line 43 ¶
	<author initials="S." surname="Dalal" fullname="Sanjay Dalal">	<author initials="S." surname="Dalal" fullname="Sanjay Dalal">
	<organization/>	<organization/>
	<address>	<address>
	<postal>	<postal>
	<country>United States of America</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>sanjay.dalal@cal.berkeley.edu</email>	<email>sanjay.dalal@cal.berkeley.edu</email>
	<uri>https://github.com/sdatspun2</uri>	<uri>https://github.com/sdatspun2</uri>
	</address>	</address>
	</author>	</author>

	<date/>	<date year="2023" month="July" />
	<area>Applications and Real-Time</area>	<area>art</area>
	<workgroup>HTTPAPI</workgroup>	<workgroup>httpapi</workgroup>
	<keyword>status</keyword>	<keyword>status</keyword>
	<keyword>HTTP</keyword>	<keyword>HTTP</keyword>
	<keyword>error</keyword>	<keyword>error</keyword>
	<keyword>problem</keyword>	<keyword>problem</keyword>
	<keyword>API</keyword>	<keyword>API</keyword>
	<keyword>JSON</keyword>	<keyword>JSON</keyword>
	<keyword>XML</keyword>	<keyword>XML</keyword>
	<abstract>	<abstract>
	<t>This document defines a "problem detail" to carry machine-readable deta ils of errors in HTTP response content to avoid the need to define new error res ponse formats for HTTP APIs.</t>	<t>This document defines a "problem detail" to carry machine-readable deta ils of errors in HTTP response content to avoid the need to define new error res ponse formats for HTTP APIs.</t>
	<t>This document obsoletes RFC 7807.</t>	<t>This document obsoletes RFC 7807.</t>
	</abstract>	</abstract>

	<note removeInRFC="true">
	<name>Discussion Venues</name>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/ietf-wg-httpapi/rfc7807bis"/>.</t>
	</note>
	</front>	</front>
	<middle>	<middle>
	<section anchor="introduction">	<section anchor="introduction">
	<name>Introduction</name>	<name>Introduction</name>

	<t>HTTP status codes (<xref section="15" sectionFormat="of" target="HTTP"/	<t>HTTP status codes (<xref section="15" sectionFormat="of" target="RFC911
	>) cannot always convey enough information about errors to be helpful. While hum	0"/>) cannot always convey enough information about errors to be helpful. While
	ans using Web browsers can often understand an HTML <xref target="HTML5"/> respo	humans using web browsers can often understand an HTML <xref target="HTML5"/> re
	nse content, non-human consumers of HTTP APIs have difficulty doing so.</t>	sponse content, non-human consumers of HTTP APIs have difficulty doing so.</t>
	<t>To address that shortcoming, this specification defines simple JSON <xr
	ef target="JSON"/> and XML <xref target="XML"/> document formats to describe the	<t>To address that shortcoming, this specification defines simple JSON <xr
	specifics of problem(s) encountered -- "problem details".</t>	ef target="RFC8259"/> and XML <xref target="XML"/> document formats to describe
	<t>For example, consider a response indicating that the client's account d	the specifics of a problem encountered -- "problem details".</t>
	oesn't have enough credit. The API's designer might decide to use the 403 Forbid	<t>For example, consider a response indicating that the client's account d
	den status code to inform HTTP-generic software (such as client libraries, cache	oesn't have enough credit. The API's designer might decide to use the 403 Forbid
	s, and proxies) of the response's general semantics. API-specific problem detail	den status code to inform generic HTTP software (such as client libraries, cache
	s (such as why the server refused the request and the applicable account balance	s, and proxies) of the response's general semantics. API-specific problem detail
	) can be carried in the response content, so that the client can act upon them a	s (such as why the server refused the request and the applicable account balance
	ppropriately (for example, triggering a transfer of more credit into the account	) can be carried in the response content so that the client can act upon them ap
	).</t>	propriately (for example, triggering a transfer of more credit into the account)
	<t>This specification identifies the specific "problem type" (e.g., "out o	.</t>
	f credit") with a URI <xref target="URI"/>. HTTP APIs can use URIs under their c	<t>This specification identifies the specific "problem type" (e.g., "out o
	ontrol to identify problems specific to them, or can reuse existing ones to faci	f credit") with a URI <xref target="RFC3986"/>. HTTP APIs can use URIs under the
	litate interoperability and leverage common semantics (see <xref target="registr	ir control to identify problems specific to them or can reuse existing ones to f
	y"/>).</t>	acilitate interoperability and leverage common semantics (see <xref target="regi
		stry"/>).</t>
	<t>Problem details can contain other information, such as a URI identifyin g the problem's specific occurrence (effectively giving an identifier to the con cept "The time Joe didn't have enough credit last Thursday"), which can be usefu l for support or forensic purposes.</t>	<t>Problem details can contain other information, such as a URI identifyin g the problem's specific occurrence (effectively giving an identifier to the con cept "The time Joe didn't have enough credit last Thursday"), which can be usefu l for support or forensic purposes.</t>

	<t>The data model for problem details is a JSON <xref target="JSON"/> obje	<t>The data model for problem details is a JSON <xref target="RFC8259"/> o
	ct; when serialized as a JSON document, it uses the "application/problem+json" m	bject; when serialized as a JSON document, it uses the "application/problem+json
	edia type. <xref target="xml-syntax"/> defines an equivalent XML format, which u	" media type. <xref target="xml-syntax"/> defines an equivalent XML format, whic
	ses the "application/problem+xml" media type.</t>	h uses the "application/problem+xml" media type.</t>
	<t>When they are conveyed in an HTTP response, the contents of problem det	<t>When they are conveyed in an HTTP response, the contents of problem det
	ails can be negotiated using proactive negotiation; see <xref section="12.1" sec	ails can be negotiated using proactive negotiation; see <xref section="12.1" sec
	tionFormat="of" target="HTTP"/>. In particular, the language used for human-read	tionFormat="of" target="RFC9110"/>. In particular, the language used for human-r
	able strings (such as those in title and description) can be negotiated using th	eadable strings (such as those in title and description) can be negotiated using
	e Accept-Language request header field (<xref section="12.5.4" sectionFormat="of	the Accept-Language request header field (<xref section="12.5.4" sectionFormat=
	" target="HTTP"/>), although that negotiation may still result in a non-preferre	"of" target="RFC9110"/>), although that negotiation may still result in a non-pr
	d, default representation being returned.</t>	eferred, default representation being returned.</t>
	<t>Problem details can be used with any HTTP status code, but they most na turally fit the semantics of 4xx and 5xx responses. Note that problem details ar e (naturally) not the only way to convey the details of a problem in HTTP. If th e response is still a representation of a resource, for example, it's often pref erable to describe the relevant details in that application's format. Likewise, defined HTTP status codes cover many situations with no need to convey extra det ail.</t>	<t>Problem details can be used with any HTTP status code, but they most na turally fit the semantics of 4xx and 5xx responses. Note that problem details ar e (naturally) not the only way to convey the details of a problem in HTTP. If th e response is still a representation of a resource, for example, it's often pref erable to describe the relevant details in that application's format. Likewise, defined HTTP status codes cover many situations with no need to convey extra det ail.</t>

	<t>This specification's aim is to define common error formats for applicat	<t>This specification's aim is to define common error formats for applicat
	ions that need one so that they aren't required to define their own, or worse, t	ions that need one so that they aren't required to define their own or, worse, t
	empted to redefine the semantics of existing HTTP status codes. Even if an appli	empted to redefine the semantics of existing HTTP status codes. Even if an appli
	cation chooses not to use it to convey errors, reviewing its design can help gui	cation chooses not to use it to convey errors, reviewing its design can help gui
	de the design decisions faced when conveying errors in an existing format.</t>	de the design decisions faced when conveying errors in an existing format.</t>
	<t>See <xref target="changes"/> for a list of changes from RFC 7807.</t>
		<t>See <xref target="changes"/> for a list of changes from <xref target="R
		FC7807"/>.</t>
	</section>	</section>

	<section anchor="notational-conventions">
	<name>Notational Conventions</name>	<section anchor="requirements-lang">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	<name>Requirements Language</name>
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"MAY", and "OPTIONAL" in this document are to be interpreted as	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	only when, they	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	appear in all capitals, as shown here.</t>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
		are to be interpreted as described in BCP 14 <xref
		target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
		appear in all capitals, as shown here.
		</t>

	</section>	</section>
	<section anchor="problem-json">	<section anchor="problem-json">
	<name>The Problem Details JSON Object</name>	<name>The Problem Details JSON Object</name>

	<t>The canonical model for problem details is a JSON <xref target="JSON"/> object. When serialized in a JSON document, that format is identified with the "application/problem+json" media type.</t>	<t>The canonical model for problem details is a JSON <xref target="RFC8259 "/> object. When serialized in a JSON document, that format is identified with t he "application/problem+json" media type.</t>
	<t>For example:</t>	<t>For example:</t>


	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	POST /purchase HTTP/1.1	POST /purchase HTTP/1.1
	Host: store.example.com	Host: store.example.com
	Content-Type: application/json	Content-Type: application/json
	Accept: application/json, application/problem+json	Accept: application/json, application/problem+json

	{	{
	"item": 123456,	"item": 123456,
	"quantity": 2	"quantity": 2
	}	}

	skipping to change at line 129 ¶	skipping to change at line 137 ¶
	Host: account.example.com	Host: account.example.com
	Accept: application/json	Accept: application/json

	{	{
	"age": 42.3,	"age": 42.3,
	"profile": {	"profile": {
	"color": "yellow"	"color": "yellow"
	}	}
	}	}
	]]></sourcecode>	]]></sourcecode>


	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 422 Unprocessable Content	HTTP/1.1 422 Unprocessable Content
	Content-Type: application/problem+json	Content-Type: application/problem+json
	Content-Language: en	Content-Language: en

	{	{
	"type": "https://example.net/validation-error",	"type": "https://example.net/validation-error",
	"title": "Your request is not valid.",	"title": "Your request is not valid.",
	"errors": [	"errors": [
	{	{
	"detail": "must be a positive integer",	"detail": "must be a positive integer",
	"pointer": "#/age"	"pointer": "#/age"
	},	},
	{	{
	"detail": "must be 'green', 'red' or 'blue'",	"detail": "must be 'green', 'red' or 'blue'",
	"pointer": "#/profile/color"	"pointer": "#/profile/color"
	}	}
	]	]
	}	}
	]]></sourcecode>	]]></sourcecode>

	<t>The fictional problem type here defines the "errors" extension, an arra
	y that describes the details of each validation error. Each member is an object	<t>The fictional problem type here defines the "errors" extension, an arra
	containing "detail" to describe the issue, and "pointer" to locate the problem w	y that describes the details of each validation error. Each member is an object
	ithin the request's content using a JSON Pointer <xref target="JSON-POINTER"/>.<	containing "detail" to describe the issue and "pointer" to locate the problem wi
	/t>	thin the request's content using a JSON Pointer <xref target="RFC6901"/>.</t>
	<t>When an API encounters multiple problems that do not share the same typ	<t>When an API encounters multiple problems that do not share the same typ
	e, it is RECOMMENDED that the most relevant or urgent problem be represented in	e, it is <bcp14>RECOMMENDED</bcp14> that the most relevant or urgent problem be
	the response. While it is possible to create generic "batch" problem types that	represented in the response. While it is possible to create generic "batch" prob
	convey multiple, disparate types, they do not map well into HTTP semantics.</t>	lem types that convey multiple, disparate types, they do not map well into HTTP
	<t>Note also that the API has responded with the application/problem+json	semantics.</t>
	type, even though the client did not list it in Accept, as is allowed by HTTP (s	<t>Note also that the API has responded with the
	ee <xref section="12.5.1" sectionFormat="of" target="HTTP"/>).</t>	"application/problem+json" type, even though the client did not list it
		in Accept, as is allowed by HTTP (see <xref section="12.5.1"
		sectionFormat="of" target="RFC9110"/>).</t>
	<section anchor="members">	<section anchor="members">


	<name>Members of a Problem Details Object</name>	<name>Members of a Problem Details Object</name>

	<t>Problem detail objects can have the following members. If a member's value type does not match the specified type, the member MUST be ignored -- i.e. , processing will continue as if the member had not been present.</t>	<t>Problem detail objects can have the following members. If a member's value type does not match the specified type, the member <bcp14>MUST</bcp14> be ignored -- i.e., processing will continue as if the member had not been present. </t>
	<section anchor="type">	<section anchor="type">
	<name>"type"</name>	<name>"type"</name>

	<t>The "type" member is a JSON string containing a URI reference <xref target="URI"/> that identifies the problem type. Consumers MUST use the "type" URI (after resolution, if necessary) as the problem type's primary identifier.</ t>	<t>The "type" member is a JSON string containing a URI reference <xref target="RFC3986"/> that identifies the problem type. Consumers <bcp14>MUST</bcp 14> use the "type" URI (after resolution, if necessary) as the problem type's pr imary identifier.</t>
	<t>When this member is not present, its value is assumed to be "about: blank".</t>	<t>When this member is not present, its value is assumed to be "about: blank".</t>

	<t>If the type URI is a locator (e.g., those with an "http" or "https"	<t>If the type URI is a locator (e.g., those with an "http" or "https"
	scheme), dereferencing it SHOULD provide human-readable documentation for the p	scheme), dereferencing it <bcp14>SHOULD</bcp14> provide human-readable document
	roblem type (e.g., using HTML <xref target="HTML5"/>). However, consumers SHOULD	ation for the problem type (e.g., using HTML <xref target="HTML5"/>). However, c
	NOT automatically dereference the type URI, unless they do so when providing in	onsumers <bcp14>SHOULD NOT</bcp14> automatically dereference the type URI, unles
	formation to developers (e.g., when a debugging tool is in use).</t>	s they do so when providing information to developers (e.g., when a debugging to
	<t>When "type" contains a relative URI, it is resolved relative to the	ol is in use).</t>
	document's base URI, as per <xref section="5" sectionFormat="comma" target="URI	<t>When "type" contains a relative URI, it is resolved relative to the
	"/>. However, using relative URIs can cause confusion, and they might not be han	document's base URI, as per <xref section="5" sectionFormat="comma" target="RFC
	dled correctly by all implementations.</t>	3986"/>. However, using relative URIs can cause confusion, and they might not be
	<t>For example, if the two resources "https://api.example.org/foo/bar/	handled correctly by all implementations.</t>
	123" and "https://api.example.org/widget/456" both respond with a "type" equal t	<t>For example, if the two resources "https://api.example.org/foo/bar/
	o the relative URI reference "example-problem", when resolved they will identify	123" and "https://api.example.org/widget/456" both respond with a "type" equal t
	different resources ("https://api.example.org/foo/bar/example-problem" and "htt	o the relative URI reference "example-problem", when resolved they will identify
	ps://api.example.org/widget/example-problem" respectively). As a result, it is R	different resources ("https://api.example.org/foo/bar/example-problem" and "htt
	ECOMMENDED that absolute URIs be used in "type" when possible, and that when rel	ps://api.example.org/widget/example-problem", respectively). As a result, it is
	ative URIs are used, they include the full path (e.g., "/types/123").</t>	<bcp14>RECOMMENDED</bcp14> that absolute URIs be used in "type" when possible an
	<t>The type URI is allowed to be a non-resolvable URI. For example, th	d that when relative URIs are used, they include the full path (e.g., "/types/12
	e tag URI scheme <xref target="TAG"/> can be used to uniquely identify problem t	3").</t>
	ypes:</t>	<t>The type URI is allowed to be a non-resolvable URI. For example, th
		e tag URI scheme <xref target="RFC4151"/> can be used to uniquely identify probl
		em types:</t>

	<artwork><![CDATA[	<artwork><![CDATA[
	tag:example@example.org,2021-09-17:OutOfLuck	tag:example@example.org,2021-09-17:OutOfLuck
	]]></artwork>	]]></artwork>


	<t>However, resolvable type URIs are encouraged by this specification because it might become desirable to resolve the URI in the future. For example, if an API designer used the URI above and later adopted a tool that resolves ty pe URIs to discover information about the error, taking advantage of that capabi lity would require switching to a resolvable URI, creating a new identity for th e problem type and thus introducing a breaking change.</t>	<t>However, resolvable type URIs are encouraged by this specification because it might become desirable to resolve the URI in the future. For example, if an API designer used the URI above and later adopted a tool that resolves ty pe URIs to discover information about the error, taking advantage of that capabi lity would require switching to a resolvable URI, creating a new identity for th e problem type and thus introducing a breaking change.</t>
	</section>	</section>
	<section anchor="status">	<section anchor="status">
	<name>"status"</name>	<name>"status"</name>

	<t>The "status" member is a JSON number indicating the HTTP status cod	<t>The "status" member is a JSON number indicating the HTTP status cod
	e (<xref section="15" sectionFormat="comma" target="HTTP"/>) generated by the or	e (<xref section="15" sectionFormat="comma" target="RFC9110"/>) generated by the
	igin server for this occurrence of the problem.</t>	origin server for this occurrence of the problem.</t>
	<t>The "status" member, if present, is only advisory; it conveys the H	<t>The "status" member, if present, is only advisory; it conveys the H
	TTP status code used for the convenience of the consumer. Generators MUST use th	TTP status code used for the convenience of the consumer. Generators <bcp14>MUST
	e same status code in the actual HTTP response, to assure that generic HTTP soft	</bcp14> use the same status code in the actual HTTP response, to assure that ge
	ware that does not understand this format still behaves correctly. See <xref tar	neric HTTP software that does not understand this format still behaves correctly
	get="security-considerations"/> for further caveats regarding its use.</t>	. See <xref target="security-considerations"/> for further caveats regarding its
	<t>Consumers can use the status member to determine what the original	use.</t>
	status code used by the generator was when it has been changed (e.g., by an inte	<t>Consumers can use the status member to determine what the original
	rmediary or cache), and when a message's content is persisted without HTTP infor	status code used by the generator was when it has been changed (e.g., by an inte
	mation. Generic HTTP software will still use the HTTP status code.</t>	rmediary or cache) and when a message's content is persisted without HTTP inform
		ation. Generic HTTP software will still use the HTTP status code.</t>
	</section>	</section>

	<section anchor="title">	<section anchor="title1">
	<name>"title"</name>	<name>"title"</name>
	<t>The "title" member is a JSON string containing a short, human-reada ble summary of the problem type.</t>	<t>The "title" member is a JSON string containing a short, human-reada ble summary of the problem type.</t>

	<t>It SHOULD NOT change from occurrence to occurrence of the problem,	<t>It <bcp14>SHOULD NOT</bcp14> change from occurrence to occurrence o
	except for localization (e.g., using proactive content negotiation; see <xref se	f the problem, except for localization (e.g., using proactive content negotiatio
	ction="12.1" sectionFormat="comma" target="HTTP"/>).</t>	n; see <xref section="12.1" sectionFormat="comma" target="RFC9110"/>).</t>
	<t>The "title" string is advisory, and is included only for users who	<t>The "title" string is advisory and is included only for users who a
	are both unaware of and cannot discover the semantics of the type URI (e.g., dur	re unaware of and cannot discover the semantics of the type URI (e.g., during of
	ing offline log analysis).</t>	fline log analysis).</t>
	</section>	</section>
	<section anchor="detail">	<section anchor="detail">
	<name>"detail"</name>	<name>"detail"</name>
	<t>The "detail" member is a JSON string containing a human-readable ex planation specific to this occurrence of the problem.</t>	<t>The "detail" member is a JSON string containing a human-readable ex planation specific to this occurrence of the problem.</t>
	<t>The "detail" string, if present, ought to focus on helping the clie nt correct the problem, rather than giving debugging information.</t>	<t>The "detail" string, if present, ought to focus on helping the clie nt correct the problem, rather than giving debugging information.</t>

	<t>Consumers SHOULD NOT parse the "detail" member for information; ext ensions are more suitable and less error-prone ways to obtain such information.< /t>	<t>Consumers <bcp14>SHOULD NOT</bcp14> parse the "detail" member for i nformation; extensions are more suitable and less error-prone ways to obtain suc h information.</t>
	</section>	</section>
	<section anchor="instance">	<section anchor="instance">
	<name>"instance"</name>	<name>"instance"</name>
	<t>The "instance" member is a JSON string containing a URI reference t hat identifies the specific occurrence of the problem.</t>	<t>The "instance" member is a JSON string containing a URI reference t hat identifies the specific occurrence of the problem.</t>

	<t>When the "instance" URI is dereferenceable, the problem details obj	<t>When the "instance" URI is dereferenceable, the problem details obj
	ect can be fetched from it. It might also return information about the problem o	ect can be fetched from it. It might also return information about the problem o
	ccurrence in other formats through use of proactive content negotiation (see <xr	ccurrence in other formats through use of proactive content negotiation (see <xr
	ef section="12.5.1" sectionFormat="comma" target="HTTP"/>).</t>	ef section="12.5.1" sectionFormat="comma" target="RFC9110"/>).</t>
	<t>When the "instance" URI is not dereferenceable, it serves as a uniq	<t>When the "instance" URI is not dereferenceable, it serves as a uniq
	ue identifier for the problem occurrence that may be of significance to the serv	ue identifier for the problem occurrence that may be of significance to the serv
	er, but is opaque to the client.</t>	er but is opaque to the client.</t>
	<t>When "instance" contains a relative URI, it is resolved relative to	<t>When "instance" contains a relative URI, it is resolved relative to
	the document's base URI, as per <xref section="5" sectionFormat="comma" target=	the document's base URI, as per <xref section="5" sectionFormat="comma" target=
	"URI"/>. However, using relative URIs can cause confusion, and they might not be	"RFC3986"/>. However, using relative URIs can cause confusion, and they might no
	handled correctly by all implementations.</t>	t be handled correctly by all implementations.</t>
	<t>For example, if the two resources "https://api.example.org/foo/bar/	<t>For example, if the two resources "https://api.example.org/foo/bar/
	123" and "https://api.example.org/widget/456" both respond with an "instance" eq	123" and "https://api.example.org/widget/456" both respond with an "instance" eq
	ual to the relative URI reference "example-instance", when resolved they will id	ual to the relative URI reference "example-instance", when resolved they will id
	entify different resources ("https://api.example.org/foo/bar/example-instance" a	entify different resources ("https://api.example.org/foo/bar/example-instance" a
	nd "https://api.example.org/widget/example-instance" respectively). As a result,	nd "https://api.example.org/widget/example-instance", respectively). As a result
	it is RECOMMENDED that absolute URIs be used in "instance" when possible, and t	, it is <bcp14>RECOMMENDED</bcp14> that absolute URIs be used in "instance" when
	hat when relative URIs are used, they include the full path (e.g., "/instances/1	possible, and that when relative URIs are used, they include the full path (e.g
	23").</t>	., "/instances/123").</t>
	</section>	</section>
	</section>	</section>
	<section anchor="extension">	<section anchor="extension">
	<name>Extension Members</name>	<name>Extension Members</name>

	<t>Problem type definitions MAY extend the problem details object with a	<t>Problem type definitions <bcp14>MAY</bcp14> extend the problem detail
	dditional members that are specific to that problem type.</t>	s object with additional members that are specific to that problem type.</t>
	<t>For example, our "out of credit" problem above defines two such exten	<t>For example, our out-of-credit problem above defines two such extensi
	sions -- "balance" and "accounts" to convey additional, problem-specific informa	ons -- "balance" and "accounts" to convey additional, problem-specific informati
	tion.</t>	on.</t>
	<t>Similarly, the "validation error" example defines an "errors" extensi on that contains a list of individual error occurrences found, with details and a pointer to the location of each.</t>	<t>Similarly, the "validation error" example defines an "errors" extensi on that contains a list of individual error occurrences found, with details and a pointer to the location of each.</t>

	<t>Clients consuming problem details MUST ignore any such extensions tha t they don't recognize; this allows problem types to evolve and include addition al information in the future.</t>	<t>Clients consuming problem details <bcp14>MUST</bcp14> ignore any such extensions that they don't recognize; this allows problem types to evolve and i nclude additional information in the future.</t>
	<t>When creating extensions, problem type authors should choose their na mes carefully. To be used in the XML format (see <xref target="xml-syntax"/>), t hey will need to conform to the Name rule in <xref section="2.3" sectionFormat=" of" target="XML" relative="#NT-Name"/>.</t>	<t>When creating extensions, problem type authors should choose their na mes carefully. To be used in the XML format (see <xref target="xml-syntax"/>), t hey will need to conform to the Name rule in <xref section="2.3" sectionFormat=" of" target="XML" relative="#NT-Name"/>.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="defining">	<section anchor="defining">
	<name>Defining New Problem Types</name>	<name>Defining New Problem Types</name>
	<t>When an HTTP API needs to define a response that indicates an error con dition, it might be appropriate to do so by defining a new problem type.</t>	<t>When an HTTP API needs to define a response that indicates an error con dition, it might be appropriate to do so by defining a new problem type.</t>

	<t>Before doing so, it's important to understand what they are good for, a	<t>Before doing so, it's important to understand what they are good for an
	nd what's better left to other mechanisms.</t>	d what is better left to other mechanisms.</t>
	<t>Problem details are not a debugging tool for the underlying implementat	<t>Problem details are not a debugging tool for the underlying implementat
	ion; rather, they are a way to expose greater detail about the HTTP interface it	ion; rather, they are a way to expose greater detail about the HTTP interface it
	self. Designers of new problem types need to carefully take into account the Sec	self. Designers of new problem types need to carefully take into account the <xr
	urity Considerations (<xref target="security-considerations"/>), in particular,	ef target="security-considerations">Security Considerations</xref>, in particula
	the risk of exposing attack vectors by exposing implementation internals through	r, the risk of exposing attack vectors by exposing implementation internals thro
	error messages.</t>	ugh error messages.</t>
	<t>Likewise, truly generic problems -- i.e., conditions that might apply t o any resource on the Web -- are usually better expressed as plain status codes. For example, a "write access disallowed" problem is probably unnecessary, since a 403 Forbidden status code in response to a PUT request is self-explanatory.</ t>	<t>Likewise, truly generic problems -- i.e., conditions that might apply t o any resource on the Web -- are usually better expressed as plain status codes. For example, a "write access disallowed" problem is probably unnecessary, since a 403 Forbidden status code in response to a PUT request is self-explanatory.</ t>
	<t>Finally, an application might have a more appropriate way to carry an e rror in a format that it already defines. Problem details are intended to avoid the necessity of establishing new "fault" or "error" document formats, not to re place existing domain-specific formats.</t>	<t>Finally, an application might have a more appropriate way to carry an e rror in a format that it already defines. Problem details are intended to avoid the necessity of establishing new "fault" or "error" document formats, not to re place existing domain-specific formats.</t>

	<t>That said, it is possible to add support for problem details to existin	<t>That said, it is possible to add support for problem details to existin
	g HTTP APIs using HTTP content negotiation (e.g., using the Accept request heade	g HTTP APIs using HTTP content negotiation (e.g., using the Accept request heade
	r to indicate a preference for this format; see <xref section="12.5.1" sectionFo	r to indicate a preference for this format; see <xref section="12.5.1" sectionFo
	rmat="comma" target="HTTP"/>).</t>	rmat="comma" target="RFC9110"/>).</t>
	<t>New problem type definitions MUST document:</t>	<t>New problem type definitions <bcp14>MUST</bcp14> document:</t>
	<ol spacing="normal" type="1"><li>a type URI (typically, with the "http" o	<ol spacing="normal" type="1">
	r "https" scheme),</li>	<li>a type URI (typically, with the "http" or "https" scheme)</li>
	<li>a title that appropriately describes it (think short), and</li>	<li>a title that appropriately describes it (think short)</li>
	<li>the HTTP status code for it to be used with.</li>	<li>the HTTP status code for it to be used with</li>
	</ol>	</ol>

	<t>Problem type definitions MAY specify the use of the Retry-After respons	<t>Problem type definitions <bcp14>MAY</bcp14> specify the use of the Retr
	e header (<xref section="10.2.3" sectionFormat="comma" target="HTTP"/>) in appro	y-After response header (<xref section="10.2.3" sectionFormat="comma" target="RF
	priate circumstances.</t>	C9110"/>) in appropriate circumstances.</t>
	<t>A problem's type URI SHOULD resolve to HTML <xref target="HTML5"/> docu
	mentation that explains how to resolve the problem.</t>	<t>A problem type URI <bcp14>SHOULD</bcp14> resolve to HTML <xref target="
	<t>A problem type definition MAY specify additional members on the problem	HTML5"/> documentation that explains how to resolve the problem.</t>
	details object. For example, an extension might use typed links <xref target="W	<t>A problem type definition <bcp14>MAY</bcp14> specify additional members
	EB-LINKING"/> to another resource that machines can use to resolve the problem.<	on the problem details object.
	/t>
	<t>If such additional members are defined, their names SHOULD start with a	For example, an extension might use typed links <xref target="RFC8288"/> to anot
	letter (ALPHA, as per <xref section="B.1" sectionFormat="comma" target="ABNF"/>	her resource that machines can use to resolve the problem.</t>
	) and SHOULD comprise characters from ALPHA, DIGIT (<xref section="B.1" sectionF	<t>If such additional members are defined, their names <bcp14>SHOULD</bcp1
	ormat="comma" target="ABNF"/>), and "_" (so that it can be serialized in formats	4> start with a letter (ALPHA, as per <xref section="B.1" sectionFormat="comma"
	other than JSON), and they SHOULD be three characters or longer.</t>	target="RFC5234"/>) and <bcp14>SHOULD</bcp14> comprise characters from ALPHA, DI
		GIT (<xref section="B.1" sectionFormat="comma" target="RFC5234"/>), and "_" (so
		that it can be serialized in formats other than JSON), and they <bcp14>SHOULD</b
		cp14> be three characters or longer.</t>
	<section anchor="example">	<section anchor="example">
	<name>Example</name>	<name>Example</name>

	<t>For example, if you are publishing an HTTP API to your online shoppin	<t>For example, if you are publishing an HTTP API to your online shoppin
	g cart, you might need to indicate that the user is out of credit (our example f	g cart, you might need to indicate that the user is out of credit (our example f
	rom above), and therefore cannot make the purchase.</t>	rom above) and therefore cannot make the purchase.</t>
	<t>If you already have an application-specific format that can accommoda	<t>If you already have an application-specific format that can accommoda
	te this information, it's probably best to do that. However, if you don't, you m	te this information, it's probably best to do that. However, if you don't, you m
	ight use one of the problem details formats -- JSON if your API is JSON-based, o	ight use one of the problem detail formats -- JSON if your API is JSON-based or
	r XML if it uses that format.</t>	XML if it uses that format.</t>
	<t>To do so, you might look in the registry (<xref target="registry"/>) for an already-defined type URI that suits your purposes. If one is available, y ou can reuse that URI.</t>	<t>To do so, you might look in the registry (<xref target="registry"/>) for an already-defined type URI that suits your purposes. If one is available, y ou can reuse that URI.</t>
	<t>If one isn't available, you could mint and document a new type URI (w hich ought to be under your control and stable over time), an appropriate title and the HTTP status code that it will be used with, along with what it means and how it should be handled.</t>	<t>If one isn't available, you could mint and document a new type URI (w hich ought to be under your control and stable over time), an appropriate title and the HTTP status code that it will be used with, along with what it means and how it should be handled.</t>
	</section>	</section>


	<section anchor="registry">	<section anchor="registry">
	<name>Registered Problem Types</name>	<name>Registered Problem Types</name>

	<t>This specification defines the HTTP Problem Type registry for common, widely-used problem type URIs, to promote reuse.</t>	<t>This specification defines the "HTTP Problem Types" registry for comm on, widely used problem type URIs, to promote reuse.</t>
	<t>The policy for this registry is Specification Required, per <xref sec tion="4.6" sectionFormat="comma" target="RFC8126"/>.</t>	<t>The policy for this registry is Specification Required, per <xref sec tion="4.6" sectionFormat="comma" target="RFC8126"/>.</t>

	<t>When evaluating requests, the Expert(s) should consider community fee	<t>When evaluating requests, the designated expert(s) should consider co
	dback, how well-defined the problem type is, and this specification's requiremen	mmunity feedback, how well-defined the problem type is, and this specification's
	ts. Vendor-specific, application-specific, and deployment-specific values are no	requirements. Vendor-specific, application-specific, and deployment-specific va
	t registerable. Specification documents should be published in a stable, freely	lues are unable to be registered. Specification documents should be published in
	available manner (ideally located with a URL), but need not be standards.</t>	a stable, freely available manner (ideally located with a URL) but need not be
	<t>Registrations MAY use the prefix "https://iana.org/assignments/http-p	standards.</t>
	roblem-types#" for the type URI. Note that those URIs may not be able to be reso	<t>Registrations <bcp14>MAY</bcp14> use the prefix "<eref target="https:
	lved.</t>	//iana.org/assignments/http-problem-types#"/>" for the type URI. Note that those
	<t>Registration requests should use the following template:</t>	URIs may not be able to be resolved.</t>
	<ul spacing="normal">
	<li>Type URI: [a URI for the problem type]</li>	<t>The following template should be used for registration requests:</t>
	<li>Title: [a short description of the problem type]</li>	<dl spacing="compact" newline="false">
	<li>Recommended HTTP status code: [what status code is most appropriat	<dt>Type URI:</dt>
	e to use with the type]</li>	<dd>[a URI for the problem type]</dd>
	<li>Reference: [to a specification defining the type]</li>	<dt>Title:</dt>
	</ul>	<dd>[a short description of the problem type]</dd>
	<t>See the registry at <eref target="https://iana.org/assignments/http-p	<dt>Recommended HTTP status code:</dt>
	roblem-types">https://iana.org/assignments/http-problem-types</eref> for details	<dd>[what status code is most appropriate to use with the type]</dd>
	on where to send registration requests.</t>	<dt>Reference:</dt>
		<dd>[to a specification defining the type]</dd>
		</dl>

		<t>See the registry at <eref target="https://iana.org/assignments/http-p
		roblem-types" brackets="angle"/> for details on where to send registration reque
		sts.</t>
	<section anchor="blank">	<section anchor="blank">
	<name>about:blank</name>	<name>about:blank</name>

	<t>This specification registers one Problem Type, "about:blank".</t>	<t>This specification registers one Problem Type, "about:blank", as fo
	<ul spacing="normal">	llows.</t>
	<li>Type URI: about:blank</li>
	<li>Title: See HTTP Status Code</li>	<dl spacing="compact" newline="false">
	<li>Recommended HTTP status code: N/A</li>	<dt>Type URI:</dt>
	<li>Reference: RFC nnnn</li>	<dd>about:blank</dd>
	</ul>	<dt>Title:</dt>
	<t>The "about:blank" URI <xref target="ABOUT"/>, when used as a proble	<dd>See HTTP Status Code</dd>
	m type, indicates that the problem has no additional semantics beyond that of th	<dt>Recommended HTTP status code:</dt>
	e HTTP status code.</t>	<dd>N/A</dd>
	<t>When "about:blank" is used, the title SHOULD be the same as the rec	<dt>Reference:</dt>
	ommended HTTP status phrase for that code (e.g., "Not Found" for 404, and so on)	<dd>RFC 9457</dd>
	, although it MAY be localized to suit client preferences (expressed with the Ac	</dl>
	cept-Language request header).</t>
		<t>The "about:blank" URI <xref target="RFC6694"/>, when used as a prob
		lem type, indicates that the problem has no additional semantics beyond that of
		the HTTP status code.</t>
		<t>When "about:blank" is used, the title <bcp14>SHOULD</bcp14> be the
		same as the recommended HTTP status phrase for that code (e.g., "Not Found" for
		404, and so on), although it <bcp14>MAY</bcp14> be localized to suit client pref
		erences (expressed with the Accept-Language request header).</t>
	<t>Please note that according to how the "type" member is defined (<xr ef target="members"/>), the "about:blank" URI is the default value for that memb er. Consequently, any problem details object not carrying an explicit "type" mem ber implicitly uses this URI.</t>	<t>Please note that according to how the "type" member is defined (<xr ef target="members"/>), the "about:blank" URI is the default value for that memb er. Consequently, any problem details object not carrying an explicit "type" mem ber implicitly uses this URI.</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>
	<section anchor="security-considerations">	<section anchor="security-considerations">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>When defining a new problem type, the information included must be care fully vetted. Likewise, when actually generating a problem -- however it is seri alized -- the details given must also be scrutinized.</t>	<t>When defining a new problem type, the information included must be care fully vetted. Likewise, when actually generating a problem -- however it is seri alized -- the details given must also be scrutinized.</t>
	<t>Risks include leaking information that can be exploited to compromise t he system, access to the system, or the privacy of users of the system.</t>	<t>Risks include leaking information that can be exploited to compromise t he system, access to the system, or the privacy of users of the system.</t>
	<t>Generators providing links to occurrence information are encouraged to avoid making implementation details such as a stack dump available through the H TTP interface, since this can expose sensitive details of the server implementat ion, its data, and so on.</t>	<t>Generators providing links to occurrence information are encouraged to avoid making implementation details such as a stack dump available through the H TTP interface, since this can expose sensitive details of the server implementat ion, its data, and so on.</t>
	<t>The "status" member duplicates the information available in the HTTP st atus code itself, bringing the possibility of disagreement between the two. Thei r relative precedence is not clear, since a disagreement might indicate that (fo r example) an intermediary has changed the HTTP status code in transit (e.g., by a proxy or cache). Generic HTTP software (such as proxies, load balancers, fire walls, and virus scanners) are unlikely to know of or respect the status code co nveyed in this member.</t>	<t>The "status" member duplicates the information available in the HTTP st atus code itself, bringing the possibility of disagreement between the two. Thei r relative precedence is not clear, since a disagreement might indicate that (fo r example) an intermediary has changed the HTTP status code in transit (e.g., by a proxy or cache). Generic HTTP software (such as proxies, load balancers, fire walls, and virus scanners) are unlikely to know of or respect the status code co nveyed in this member.</t>
	</section>	</section>
	<section anchor="iana-considerations">	<section anchor="iana-considerations">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

	<t>Please update the "application/problem+json" and "application/problem+x	<t>In the "application" registry under the "Media Types" registry, IANA ha
	ml" registrations in the "Media Types" registry to refer to this document.</t>	s updated the "application/problem+json" and "application/problem+xml" registrat
	<t>Please create the "HTTP Problem Types" registry as specified in <xref t	ions to refer to this document.</t>
	arget="registry"/>, and populate it with "about:blank" as per <xref target="blan	<t>IANA has created the "HTTP Problem Types" registry as specified in <xre
	k"/>.</t>	f target="registry"/> and populated it with "about:blank" as per <xref target="b
		lank"/>.</t>
	</section>	</section>
	</middle>	</middle>
	<back>	<back>


		<displayreference target="RFC3986" to="URI"/>
		<displayreference target="RFC5234" to="ABNF"/>
		<displayreference target="RFC8259" to="JSON"/>
		<displayreference target="RFC9110" to="HTTP"/>
		<displayreference target="RFC8288" to="WEB-LINKING"/>
		<displayreference target="RFC6694" to="ABOUT"/>
		<displayreference target="RFC4151" to="TAG"/>
		<displayreference target="RFC6901" to="JSON-POINTER"/>
		<displayreference target="I-D.bhutton-json-schema" to="JSON-SCHEMA"/>

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

	<reference anchor="RFC2119">
	<front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit	/>
	le>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"
	<author fullname="S. Bradner" initials="S." surname="Bradner">	/>
	<organization/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
	</author>	/>
	<date month="March" year="1997"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
	<abstract>	/>
	<t>In many standards track documents several words are used to sig	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"
	nify the requirements in the specification. These words are often capitalized.	/>
	This document defines these words as they should be interpreted in IETF document	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"
	s. This document specifies an Internet Best Current Practices for the Internet	/>
	Community, 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="URI">
	<front>
	<title>Uniform Resource Identifier (URI): Generic Syntax</title>
	<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
	">
	<organization/>
	</author>
	<author fullname="R. Fielding" initials="R." surname="Fielding">
	<organization/>
	</author>
	<author fullname="L. Masinter" initials="L." surname="Masinter">
	<organization/>
	</author>
	<date month="January" year="2005"/>
	<abstract>
	<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
	aracters that identifies an abstract or physical resource. This specification d
	efines the generic URI syntax and a process for resolving URI references that mi
	ght be in relative form, along with guidelines and security considerations for t
	he use of URIs on the Internet. The URI syntax defines a grammar that is a supe
	rset of all valid URIs, allowing an implementation to parse the common component
	s of a URI reference without knowing the scheme-specific requirements of every p
	ossible identifier. This specification does not define a generative grammar for
	URIs; that task is performed by the individual specifications of each URI schem
	e. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="66"/>
	<seriesInfo name="RFC" value="3986"/>
	<seriesInfo name="DOI" value="10.17487/RFC3986"/>
	</reference>
	<reference anchor="ABNF">
	<front>
	<title>Augmented BNF for Syntax Specifications: ABNF</title>
	<author fullname="D. Crocker" initials="D." role="editor" surname="C
	rocker">
	<organization/>
	</author>
	<author fullname="P. Overell" initials="P." surname="Overell">
	<organization/>
	</author>
	<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 A
	ugmented BNF (ABNF), has been popular among many Internet specifications. The c
	urrent specification documents ABNF. It balances compactness and simplicity with
	reasonable representational power. The differences between standard BNF and AB
	NF involve naming rules, repetition, alternatives, order-independence, and value
	ranges. This specification also supplies additional rule definitions and encod
	ing for a core lexical analyzer of the type common to several Internet specifica
	tions. [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="RFC8126">
	<front>
	<title>Guidelines for Writing an IANA Considerations Section in RFCs
	</title>
	<author fullname="M. Cotton" initials="M." surname="Cotton">
	<organization/>
	</author>
	<author fullname="B. Leiba" initials="B." surname="Leiba">
	<organization/>
	</author>
	<author fullname="T. Narten" initials="T." surname="Narten">
	<organization/>
	</author>
	<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 th
	ese fields do not have conflicting uses and to promote interoperability, their a
	llocations 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 documen
	t defines a framework for the documentation of these guidelines by specification
	authors, in order to assure that the provided guidance for the IANA Considerati
	ons is clear and addresses the various issues that are likely in the operation o
	f 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>
	<reference anchor="JSON">
	<front>
	<title>The JavaScript Object Notation (JSON) Data Interchange Format
	</title>
	<author fullname="T. Bray" initials="T." role="editor" surname="Bray
	">
	<organization/>
	</author>
	<date month="December" year="2017"/>
	<abstract>
	<t>JavaScript Object Notation (JSON) is a lightweight, text-based,
	language-independent data interchange format. It was derived from the ECMAScri
	pt Programming Language Standard. JSON defines a small set of formatting rules
	for the portable representation of structured data.</t>
	<t>This document removes inconsistencies with other specifications
	of JSON, repairs specification errors, and offers experience-based interoperabi
	lity guidance.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="90"/>
	<seriesInfo name="RFC" value="8259"/>
	<seriesInfo name="DOI" value="10.17487/RFC8259"/>
	</reference>
	<reference anchor="HTTP">
	<front>
	<title>HTTP Semantics</title>
	<author fullname="R. Fielding" initials="R." role="editor" surname="
	Fielding">
	<organization/>
	</author>
	<author fullname="M. Nottingham" initials="M." role="editor" surname
	="Nottingham">
	<organization/>
	</author>
	<author fullname="J. Reschke" initials="J." role="editor" surname="R
	eschke">
	<organization/>
	</author>
	<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="XML" target="https://www.w3.org/TR/2008/REC-xml-20081 126/">	<reference anchor="XML" target="https://www.w3.org/TR/2008/REC-xml-20081 126/">
	<front>	<front>
	<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>	<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>

	<author fullname="Eve Maler" role="editor"/>	<author initials="T." surname="Bray"/>
	<author fullname="François Yergeau" role="editor"/>	<author initials="J." surname="Paoli"/>
	<author fullname="Jean Paoli" role="editor"/>	<author initials="C. M." surname="Sperberg-McQueen"/>
	<author fullname="Michael Sperberg-McQueen" role="editor"/>	<author initials="E." surname="Maler"/>
	<author fullname="Tim Bray" role="editor"/>	<author initials="F." surname="Yergeau"/>
	<date day="26" month="November" year="2008"/>	<date month="November" year="2008"/>
	</front>
	<seriesInfo name="W3C REC" value="REC-xml-20081126"/>
	<seriesInfo name="W3C" value="REC-xml-20081126"/>
	</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">
	<organization/>
	</author>
	<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 tha
	t only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>	</front>

	<seriesInfo name="BCP" value="14"/>	<refcontent>W3C Recommendation REC-xml-20081126</refcontent>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>	</reference>


		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
		/>

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

	<reference anchor="WEB-LINKING">
	<front>
	<title>Web Linking</title>
	<author fullname="M. Nottingham" initials="M." surname="Nottingham">
	<organization/>
	</author>
	<date month="October" year="2017"/>
	<abstract>
	<t>This specification defines a model for the relationships betwee
	n resources on the Web ("links") and the type of those relationships ("link rela
	tion types").</t>
	<t>It also defines the serialisation of such links in HTTP headers
	with the Link header field.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8288"/>
	<seriesInfo name="DOI" value="10.17487/RFC8288"/>
	</reference>
	<reference anchor="ABOUT">
	<front>
	<title>The "about" URI Scheme</title>
	<author fullname="S. Moonesamy" initials="S." role="editor" surname=
	"Moonesamy">
	<organization/>
	</author>
	<date month="August" year="2012"/>
	<abstract>
	<t>This document describes the "about" URI scheme, which is widely
	used by Web browsers and some other applications to designate access to their i
	nternal resources, such as settings, application information, hidden built-in fu
	nctionality, and so on. This document is not an Internet Standards Track speci
	fication; it is published for informational purposes.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6694"/>
	<seriesInfo name="DOI" value="10.17487/RFC6694"/>
	</reference>
	<reference anchor="TAG">
	<front>
	<title>The 'tag' URI Scheme</title>
	<author fullname="T. Kindberg" initials="T." surname="Kindberg">
	<organization/>
	</author>
	<author fullname="S. Hawke" initials="S." surname="Hawke">
	<organization/>
	</author>
	<date month="October" year="2005"/>
	<abstract>
	<t>This document describes the "tag" Uniform Resource Identifier (
	URI) scheme. Tag URIs (also known as "tags") are designed to be unique across s
	pace and time while being tractable to humans. They are distinct from most othe
	r URIs in that they have no authoritative resolution mechanism. A tag may be us
	ed purely as an entity identifier. Furthermore, using tags has some advantages
	over the common practice of using "http" URIs as identifiers for non-HTTP-access
	ible resources. This memo provides information for the Internet community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4151"/>
	<seriesInfo name="DOI" value="10.17487/RFC4151"/>
	</reference>
	<reference anchor="JSON-POINTER">
	<front>
	<title>JavaScript Object Notation (JSON) Pointer</title>
	<author fullname="P. Bryan" initials="P." role="editor" surname="Bry
	an">
	<organization/>
	</author>
	<author fullname="K. Zyp" initials="K." surname="Zyp">
	<organization/>
	</author>
	<author fullname="M. Nottingham" initials="M." role="editor" surname
	="Nottingham">
	<organization/>
	</author>
	<date month="April" year="2013"/>
	<abstract>
	<t>JSON Pointer defines a string syntax for identifying a specific
	value within a JavaScript Object Notation (JSON) document.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6901"/>
	<seriesInfo name="DOI" value="10.17487/RFC6901"/>
	</reference>
	<reference anchor="JSON-SCHEMA">
	<front>
	<title>JSON Schema: A Media Type for Describing JSON Documents</titl
	e>
	<author fullname="Austin Wright" initials="A." surname="Wright">
	</author>
	<author fullname="Henry Andrews" initials="H." surname="Andrews">
	</author>
	<author fullname="Ben Hutton" initials="B." surname="Hutton">
	<organization>Postman</organization>
	</author>
	<author fullname="Greg Dennis" initials="G." surname="Dennis">
	</author>
	<date day="10" month="June" year="2022"/>
	<abstract>
	<t> JSON Schema defines the media type "application/schema+json"
	, a JSON-
	based format for describing the structure of JSON data. JSON Schema
	asserts what a JSON document must look like, ways to extract
	information from it, and how to interact with it. The "application/
	schema-instance+json" media type provides additional feature-rich
	integration with "application/schema+json" beyond what can be offered
	for "application/json" documents.


	</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8288.xml"
	</abstract>	/>
	</front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6694.xml"
	<seriesInfo name="Internet-Draft" value="draft-bhutton-json-schema-01"	/>
	/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4151.xml"
	</reference>	/>
	<reference anchor="ISO-19757-2">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6901.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7807.xml"
		/>

		<!-- [JSON-SCHEMA] [I-D.bhutton-json-schema] IESG state Expired. Updated to long
		verson because xi:include missing editor role -->
		<reference anchor="I-D.bhutton-json-schema" target="https://datatracker.ietf.org
		/doc/html/draft-bhutton-json-schema-01">
		<front>
		<title>JSON Schema: A Media Type for Describing JSON Documents</title>
		<author initials="A." surname="Wright" fullname="Austin Wright" role="editor"> <
		/author>
		<author initials="H." surname="Andrews" fullname="Henry Andrews" role="editor">
		</author>
		<author initials="B." surname="Hutton" fullname="Ben Hutton" role="editor">
		<organization>Postman</organization>
		</author>
		<author initials="G." surname="Dennis" fullname="Greg Dennis"> </author>
		<date month="June" day="10" year="2022"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-bhutton-json-schema-01"/>
		</reference>

		<reference anchor="ISO-19757-2" target="https://www.iso.org/standard/523
		48.html">
	<front>	<front>

	<title>Information Technology -- Document Schema Definition Language	<title>Information technology -- Document Schema Definition
	s (DSDL) -- Part 2: Grammar-based Validation -- RELAX NG</title>	Language (DSDL) -- Part 2: Regular-grammar-based validation --
		RELAX NG</title>
	<author>	<author>

	<organization>International Organization for Standardization</orga nization>	<organization>ISO</organization>
	</author>	</author>

	<date year="2003"/>	<date month="December" year="2008"/>
	</front>	</front>

	<seriesInfo name="ISO/IEC" value="19757-2"/>	<seriesInfo name="ISO/IEC" value="19757-2:2008"/>
	</reference>	</reference>


	<reference anchor="HTML5" target="https://html.spec.whatwg.org">	<reference anchor="HTML5" target="https://html.spec.whatwg.org">
	<front>	<front>

	<title>HTML - Living Standard</title>	<title>HTML: Living Standard</title>
	<author>	<author>
	<organization>WHATWG</organization>	<organization>WHATWG</organization>
	</author>	</author>

	<date>n.d.</date>	<date></date>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="RDFA" target="https://www.w3.org/TR/2015/REC-rdfa-cor e-20150317/">	<reference anchor="RDFA" target="https://www.w3.org/TR/2015/REC-rdfa-cor e-20150317/">
	<front>	<front>
	<title>RDFa Core 1.1 - Third Edition</title>	<title>RDFa Core 1.1 - Third Edition</title>

	<author fullname="Ben Adida" role="editor"/>	<author fullname="Ben Adida"/>
	<author fullname="Ivan Herman" role="editor"/>	<author fullname="Mark Birbeck"/>
	<author fullname="Mark Birbeck" role="editor"/>	<author fullname="Shane McCarron"/>
	<author fullname="Shane McCarron" role="editor"/>	<author fullname="Ivan Herman"/>
	<date day="17" month="March" year="2015"/>	<date month="March" year="2015"/>
	</front>	</front>

	<seriesInfo name="W3C REC" value="REC-rdfa-core-20150317"/>	<refcontent>W3C Recommendation</refcontent>
	<seriesInfo name="W3C" value="REC-rdfa-core-20150317"/>
	</reference>	</reference>


	<reference anchor="XSLT" target="https://www.w3.org/TR/2010/REC-xml-styl esheet-20101028/">	<reference anchor="XSLT" target="https://www.w3.org/TR/2010/REC-xml-styl esheet-20101028/">
	<front>	<front>
	<title>Associating Style Sheets with XML documents 1.0 (Second Editi on)</title>	<title>Associating Style Sheets with XML documents 1.0 (Second Editi on)</title>

	<author fullname="Henry Thompson" role="editor"/>	<author fullname="James Clark"/>
	<author fullname="James Clark" role="editor"/>	<author fullname="Simon Pieters"/>
	<author fullname="Simon Pieters" role="editor"/>	<author fullname="Henry Thompson"/>
	<date day="28" month="October" year="2010"/>	<date month="October" year="2010"/>
	</front>	</front>

	<seriesInfo name="W3C REC" value="REC-xml-stylesheet-20101028"/>	<refcontent>W3C Recommendation</refcontent>
	<seriesInfo name="W3C" value="REC-xml-stylesheet-20101028"/>
	</reference>	</reference>


	</references>	</references>
	</references>	</references>


	<section anchor="json-schema">	<section anchor="json-schema">
	<name>JSON Schema for HTTP Problems</name>	<name>JSON Schema for HTTP Problems</name>

	<t>This section presents a non-normative JSON Schema <xref target="JSON-SC	<t>This section presents a non-normative JSON Schema <xref target="I-D.bhu
	HEMA"/> for HTTP Problem Details. If there is any disagreement between it and th	tton-json-schema"/> for HTTP problem details. If there is any disagreement betwe
	e text of the specification, the latter prevails.</t>	en it and the text of the specification, the latter prevails.</t>

	<sourcecode type="json"><![CDATA[	<sourcecode type="json"><![CDATA[
	# NOTE: '\' line wrapping per RFC 8792	# NOTE: '\' line wrapping per RFC 8792
	{	{
	"$schema": "https://json-schema.org/draft/2020-12/schema",	"$schema": "https://json-schema.org/draft/2020-12/schema",

	"title": "An RFC7807 problem object",	"title": "An RFC 7807 problem object",
	"type": "object",	"type": "object",
	"properties": {	"properties": {
	"type": {	"type": {
	"type": "string",	"type": "string",
	"format": "uri-reference",	"format": "uri-reference",
	"description": "A URI reference that identifies the \	"description": "A URI reference that identifies the \
	problem type."	problem type."
	},	},
	"title": {	"title": {
	"type": "string",	"type": "string",

	skipping to change at line 601 ¶	skipping to change at line 460 ¶
	"instance": {	"instance": {
	"type": "string",	"type": "string",
	"format": "uri-reference",	"format": "uri-reference",
	"description": "A URI reference that identifies the \	"description": "A URI reference that identifies the \
	specific occurrence of the problem. It may or may not yield \	specific occurrence of the problem. It may or may not yield \
	further information if dereferenced."	further information if dereferenced."
	}	}
	}	}
	}	}
	]]></sourcecode>	]]></sourcecode>


	</section>	</section>
	<section anchor="xml-syntax">	<section anchor="xml-syntax">
	<name>HTTP Problems and XML</name>	<name>HTTP Problems and XML</name>
	<t>HTTP-based APIs that use XML <xref target="XML"/> can express problem d etails using the format defined in this appendix.</t>	<t>HTTP-based APIs that use XML <xref target="XML"/> can express problem d etails using the format defined in this appendix.</t>
	<t>The RELAX NG schema <xref target="ISO-19757-2"/> for the XML format is: </t>	<t>The RELAX NG schema <xref target="ISO-19757-2"/> for the XML format is: </t>

	<sourcecode type="relax-ng-compact-syntax"><![CDATA[
		<sourcecode type="rnc"><![CDATA[
	default namespace ns = "urn:ietf:rfc:7807"	default namespace ns = "urn:ietf:rfc:7807"

	start = problem	start = problem

	problem =	problem =
	element problem {	element problem {
	( element type { xsd:anyURI }?	( element type { xsd:anyURI }?
	& element title { xsd:string }?	& element title { xsd:string }?
	& element detail { xsd:string }?	& element detail { xsd:string }?
	& element status { xsd:positiveInteger }?	& element status { xsd:positiveInteger }?
	& element instance { xsd:anyURI }? ),	& element instance { xsd:anyURI }? ),
	anyNsElement	anyNsElement
	}	}

	anyNsElement =	anyNsElement =
	( element ns:* { anyNsElement \| text }	( element ns:* { anyNsElement \| text }
	\| attribute * { text })*	\| attribute * { text })*
	]]></sourcecode>	]]></sourcecode>

	<t>Note that this schema is only intended as documentation, and not as a n
	ormative schema that captures all constraints of the XML format. It is possible	<t>Note that this schema is only intended as documentation and not as a no
	to use other XML schema languages to define a similar set of constraints (depend	rmative schema that captures all constraints of the XML format. It is possible t
	ing on the features of the chosen schema language).</t>	o use other XML schema languages to define a similar set of constraints (dependi
		ng on the features of the chosen schema language).</t>
	<t>The media type for this format is "application/problem+xml".</t>	<t>The media type for this format is "application/problem+xml".</t>

	<t>Extension arrays and objects are serialized into the XML format by cons
	idering an element containing a child or children to represent an object, except	<t>Extension arrays and objects are serialized into the XML format by cons
	for elements that contain only child element(s) named 'i', which are considered	idering an element containing a child or children to represent an object, except
	arrays. For example, the example above appears in XML as follows:</t>	for elements containing only one or more child elements named "i", which are co
		nsidered arrays. For example, the example above appears in XML as follows:</t>

	<sourcecode type="http-message"><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 403 Forbidden	HTTP/1.1 403 Forbidden
	Content-Type: application/problem+xml	Content-Type: application/problem+xml
	Content-Language: en	Content-Language: en

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<problem xmlns="urn:ietf:rfc:7807">	<problem xmlns="urn:ietf:rfc:7807">
	<type>https://example.com/probs/out-of-credit</type>	<type>https://example.com/probs/out-of-credit</type>
	<title>You do not have enough credit.</title>	<title>You do not have enough credit.</title>
	<detail>Your current balance is 30, but that costs 50.</detail>	<detail>Your current balance is 30, but that costs 50.</detail>
	<instance>https://example.net/account/12345/msgs/abc</instance>	<instance>https://example.net/account/12345/msgs/abc</instance>
	<balance>30</balance>	<balance>30</balance>
	<accounts>	<accounts>
	<i>https://example.net/account/12345</i>	<i>https://example.net/account/12345</i>
	<i>https://example.net/account/67890</i>	<i>https://example.net/account/67890</i>
	</accounts>	</accounts>
	</problem>	</problem>
	]]></sourcecode>	]]></sourcecode>

	<t>This format uses an XML namespace, primarily to allow embedding it into
	other XML-based formats; it does not imply that it can or should be extended wi	<t>This format uses an XML namespace, primarily to allow embedding it into
	th elements or attributes in other namespaces. The RELAX NG schema explicitly on	other XML-based formats; it does not imply that it can or should be extended wi
	ly allows elements from the one namespace used in the XML format. Any extension	th elements or attributes in other namespaces. The RELAX NG schema explicitly on
	arrays and objects MUST be serialized into XML markup using only that namespace.	ly allows elements from the one namespace used in the XML format. Any extension
	</t>	arrays and objects <bcp14>MUST</bcp14> be serialized into XML markup using only
	<t>When using the XML format, it is possible to embed an XML processing in	that namespace.</t>
	struction in the XML that instructs clients to transform the XML, using the refe	<t>When using the XML format, it is possible to embed an XML processing in
	renced XSLT code <xref target="XSLT"/>. If this code is transforming the XML int	struction in the XML that instructs clients to transform the XML, using the refe
	o (X)HTML, then it is possible to serve the XML format, and yet have clients cap	renced XSL Transformations (XSLT) code <xref target="XSLT"/>. If this code is t
	able of performing the transformation display human-friendly (X)HTML that is ren	ransforming the XML into (X)HTML, then it is possible to serve the XML format, a
	dered and displayed at the client. Note that when using this method, it is advis	nd yet have clients capable of performing the transformation display human-frien
	able to use XSLT 1.0 in order to maximize the number of clients capable of execu	dly (X)HTML that is rendered and displayed at the client. Note that when using t
	ting the XSLT code.</t>	his method, it is advisable to use XSLT 1.0 in order to maximize the number of c
		lients capable of executing the XSLT code.</t>
	</section>	</section>
	<section anchor="using-problem-details-with-other-formats">	<section anchor="using-problem-details-with-other-formats">
	<name>Using Problem Details with Other Formats</name>	<name>Using Problem Details with Other Formats</name>
	<t>In some situations, it can be advantageous to embed problem details in formats other than those described here. For example, an API that uses HTML <xre f target="HTML5"/> might want to also use HTML for expressing its problem detail s.</t>	<t>In some situations, it can be advantageous to embed problem details in formats other than those described here. For example, an API that uses HTML <xre f target="HTML5"/> might want to also use HTML for expressing its problem detail s.</t>
	<t>Problem details can be embedded in other formats either by encapsulatin g one of the existing serializations (JSON or XML) into that format or by transl ating the model of a problem detail (as specified in <xref target="problem-json" />) into the format's conventions.</t>	<t>Problem details can be embedded in other formats either by encapsulatin g one of the existing serializations (JSON or XML) into that format or by transl ating the model of a problem detail (as specified in <xref target="problem-json" />) into the format's conventions.</t>
	<t>For example, in HTML, a problem could be embedded by encapsulating JSON in a script tag:</t>	<t>For example, in HTML, a problem could be embedded by encapsulating JSON in a script tag:</t>

	<sourcecode type="html"><![CDATA[
		<sourcecode type=""><![CDATA[
	<script type="application/problem+json">	<script type="application/problem+json">
	{	{
	"type": "https://example.com/probs/out-of-credit",	"type": "https://example.com/probs/out-of-credit",
	"title": "You do not have enough credit.",	"title": "You do not have enough credit.",
	"detail": "Your current balance is 30, but that costs 50.",	"detail": "Your current balance is 30, but that costs 50.",
	"instance": "/account/12345/msgs/abc",	"instance": "/account/12345/msgs/abc",
	"balance": 30,	"balance": 30,
	"accounts": ["/account/12345",	"accounts": ["/account/12345",
	"/account/67890"]	"/account/67890"]
	}	}
	</script>	</script>
	]]></sourcecode>	]]></sourcecode>

	<t>or by defining a mapping into RDFa <xref target="RDFA"/>.</t>
		<t>or by defining a mapping into a Resource Description
		Framework in Attributes (RDFa) <xref target="RDFA"/>.</t>
	<t>This specification does not make specific recommendations regarding emb edding problem details in other formats; the appropriate way to embed them depen ds both upon the format in use and application of that format.</t>	<t>This specification does not make specific recommendations regarding emb edding problem details in other formats; the appropriate way to embed them depen ds both upon the format in use and application of that format.</t>
	</section>	</section>
	<section anchor="changes">	<section anchor="changes">
	<name>Changes from RFC 7807</name>	<name>Changes from RFC 7807</name>
	<t>This revision has made the following changes:</t>	<t>This revision has made the following changes:</t>
	<ul spacing="normal">	<ul spacing="normal">

	<li>	<li> <xref target="registry"/> introduces a registry of common problem
	<xref target="registry"/> introduces a registry of common problem type	type URIs</li>
	URIs</li>	<li> <xref target="problem-json"/> clarifies how multiple problems
	<li>	should be treated</li>
	<xref target="problem-json"/> clarifies how multiple problems should b	<li> <xref target="type"/> provides guidance for using type URIs that
	e treated</li>	cannot be dereferenced</li>
	<li>
	<xref target="type"/> provides guidance for using type URIs that canno
	t be dereferenced</li>
	</ul>	</ul>
	</section>	</section>
	<section numbered="false" anchor="acknowledgements">	<section numbered="false" anchor="acknowledgements">
	<name>Acknowledgements</name>	<name>Acknowledgements</name>
	<t>The authors would like to thank	<t>The authors would like to thank

	Jan Algermissen,	<contact fullname="Jan Algermissen"/>,
	Subbu Allamaraju,	<contact fullname="Subbu Allamaraju"/>,
	Mike Amundsen,	<contact fullname="Mike Amundsen"/>,
	Roy Fielding,	<contact fullname="Roy Fielding"/>,
	Eran Hammer,	<contact fullname="Eran Hammer"/>,
	Sam Johnston,	<contact fullname="Sam Johnston"/>,
	Mike McCall,	<contact fullname="Mike McCall"/>,
	Julian Reschke, and	<contact fullname="Julian Reschke"/>, and
	James Snell	<contact fullname="James Snell"/>
	for their comments and suggestions.</t>	for their comments and suggestions.</t>
	</section>	</section>

	</back>	</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA+1de3cTSXb/X5+iInIC3kjyAxhAA+x6wAyegCHYZHZPJien
	pS5JvW51a/thWet4P0s+Sz5ZfvdR1dUtmYFN9uSfzJ5gqVVddevWfT8qw+Gw
	VyVVasfmY5FPUrs0r20VJWlpZnlh3l5cfDTHH0/LXjSZFPZq3IvzaRYtMTwu
	olk1TGw1Gy6qahWtkmExmz55evBkkpTDgye9OKow7Ob18cXJbW+KL/O82IxN
	WcW9fFLmqa1sOTb0Qq+XrIqxqYq6rI4ODp4dHPWiwkZjc7xapQleTfKsNFEW
	m082SocXydL21nlxOS/yejVmIAFj79Ju8DQe94wZYpmoqkv+SL/zB1sUecGf
	VrJX/kyv0t+fzj+c8Yffv3/X612NzcOezYCbDU14fvLuzdj0P715ZTL81+/1
	orpa5AV+G+JnY5IMm3k/Mmd5VSXZfBEt+bHg6n1UXHZ/yYt5lCV/5s2N+ckq
	B9CpfCY4PhbRoogy/j7N66wi9B0DR0WUJhE/tksc1dgss7z6Hf0zymzFP9RF
	MjZ0LuV4f3+9Xo/cr/stgE9G5uckjW0A60mRXAYPt8HUNS3GjdY07ndxYXes
	jIXdD/v4P/rcXvx8ZF5HaZQGi59H2R+jTfB4e3mPic9ZUtnYnOOgbWnymTle
	AqZpCzElzzeKab7fTaN0NLHFpU3tZmTjehtR86Ra1JPRNF/ulyDfclVnR71e
	L8uLJSC4sgQBSODo8PAZffz86XRM3x8+e/odvh7/cPaGvz8+evhIRj49PPqO
	RhJt8U9Pjx4/w3ciSf7+7PDwAN9BcmPz88NXo08nr4bXy3QINnh6iJfBGtks
	XP7nkx+G707P/un07Eed8OlTXvvD5wt+8N13z2jxi2P5/dHh40MFYPjxw+nZ
	xcknGfbswD8/f/X25P3x2JwOX4+ErSeLuqrybPjHEv+U0wXQicGn5x+Gh8+e
	PH4yPJKzUMnRP3Uw5pm5sNNFlqf5fGOGQ/M6n9ZLsJE550kgXGYJzo0Gvouy
	eR3NcXYPXp+/frdHwz9GRWWOxubHIlouo2I4iUoc8b+A3mOZHWM+nbw7/r05
	+7HPIHg2ZJ5R3mG6wX6yyhYZvxil5kNASizcQDlZHBWxPuN3RWgB+w/5awmK
	siUdgWNL4GD/9OTV2Cgi+DDfv3usCImKua0aglpUy3RUrux0tF5E1Xo+Alwh
	5uhVcPq75AqSwQP0qxv7+e3xxc8/Eom9fnPcEE4Rz6LhNC8syOfw8cHDwydE
	WufvLtq0VVab1JYLaysah/8dPQWRD4HaaELCZVr1eheLpDSxO7yYTg0HFZm+
	Sk48Ii3RN1VuplFRbMwymi4waAjBHUcYoiOYM1nwluB6USiFLVeQ6Ba8jBPC
	/JgkusqT2FQLazKLI8cTWRRf1/J+85oQW0dDjbpAeyVD5M56ZsSbXCZxnFrs
	+B4RSJHH9ZSPv8dTid4AZDER5s3NueVfzeFj2ggNub3dw5YzyFMTpetoQ4Oz
	K7sxNsvr+cIkATNEk7yu3Paxp4k1C5uuZnUKwbtIgKVFvYyg3OqSCOBnOzGT
	Il+D7EpaA0sCP6bOYjwg4oASFJq5uWGqu73dQubAZOBZnpYelUBGUTrYGVNm
	EV3heJLZLJnWabUBymjxMicU4iRiiOoS4IJiTQkarCAPMWCAJ8AvUXMyU63s
	KaNMlivshsQJYKM/AI0A/j0Di3/x3R+NO0A+5XJaJMALHb2bm+FVSntQ7gGz
	LPVtAcrACXaIsOwD8DegBXsdERQD3ncCnIFgPXqSLGagsVPeGa03TROAcx+E
	PeUFAKEts/uVYEjPc4pVk2pkLvAC0IfRgDmZZ5h+mcwXxB1TLEabqUvZx6OD
	hwYATUBpOL6ApGiQ0Acfx3BuM9JZwP2sWsPmMQ/KerowUamgmTSZFBHJIGwK
	DEZ/CatAwDUe7hGeaEG3SwDHU0LclRC3MF+m5YigHjrUmg7umhXXi40cgi2u
	LHHbrCbhK9P/qbZlxUvT90jsMuJyh7kJVGw2tcwaROYkFBK8Dp4PAWyotMy7
	58CvQvqYGkPp+ZIWKvJVkUAqpxvzYBYeclUk8zmwhwON8AVcNAPYQMgSElBP
	DctXuYAscO45MdEmY5wfcDUDSlt02FBatVnZvnlgR/PRwPSJqbGQrNHfM2vY
	DQAC9gBoHf/e3o4CdqNtEWXgh1J4mRZJCsZFkadMFALAxh1PA6CRDSwHEP08
	VWFpMnudlEzMObEfxsyiaZImZAzRpi3QBjKY0KMNn1tqcapQt1h1ucSWPX2A
	AqwF3IWdY8piA/kGJH3skMlUxAm+QCoBniKUczhNJSJBgtuNMJt1m7of7Cqf
	TuuiAGOD5u1sRlL2is54LqowCs6kUBTQ+lO7qkyfWLGCF2B+ykmQxbtZ1qQR
	aPZiURcw5jb9vQFIPAGYSqHAIuQwK5GyXq0g5wjD+GohPMAndQGD3IpesWQY
	RKCs2MobXS5KaOtt6ZdP/ohdfY9FSQaAUGHF/BkcEfmhTh4ODIAFOEJ8/ajx
	evZ1nX8kQ6xvlthWxLQ4wjqsyzc4kmuSrU5FZwbMmlxFKXEUSV85Jbf5Ly+D
	KVur9Ho/E/QYDyIqrGo6Yeuoo80H7oyIv0MJ3qKhCWn0eV4RS8eq9jAu4vP3
	PwGm742QpVfAR6PDRgWPoLvNCtYiqbCokLVTtSgNCy46JlaDjUkC8sZ6gcyD
	icWqQewx5hNRSCtac+9OiGm14ykR49CZsV5ILrAaaBaEm8YtC+Jo9Hj0KLAi
	IMpTAEAEy5Iw2DysqQ2gTdKU0AslzQhnzb6CYIZBYeMBnXlEvxUWD0tgXd6d
	WAIR7lZdZDa+g5cniiURXdnGdK2fgZnUlZz8Eo4pHDTMF6Vg0VlSqaJwEgR7
	enR9zeh7jL+OIkp2h63srksMrO38pHuG7CmaNc+wBMwqtizFsKLHgTUZ+bnU
	oAQxtNUgsaNgL+oih9/Hg7wupthjS6MkZAqIySVYZqLpGikF/MeriK1i5f1M
	dhgw1P1S2W4E2/7SrhNiD2HReAvT9C9p3CUdQ5lUtQY8+Giy3BvEzsy8hrLT
	xXdqM7JnkiXhoLGiVeiLIR3az1EYYlEyxHLQKqGGZu4nKUtEnhQtA110Wb7O
	WEOtYemSKLDLVSXDMNoPbNOM12FbGBmZkyucQjIjKROAaKaLnISyUIsYXEkV
	IodN7QEWvUqAdsydVM5gY7on89vMazbYmKz4FzLhSkYB1ChxBUk9mZLmaPwX
	Eq8Oaj3hXu+cBdV0AUlgS8hixitMt1KsBHluZkW+DFwR8j/AHc47fUWLZXwM
	onAusRsKZ5Wm//7z+UV/IH/N2Qf+/Onknz+ffjp5TZ/P3x6/e+c/9HTE+dsP
	n9+9bj41b7768P79ydlreRlPTetRr//++A99sTP7Hz5enH44O37XFyoP/Sti
	YHFp2N4Ax1Ss3XqOW1hL/PDq43/95+Ej4OfvNHICBMmXp4dPHuEL4VpWE9bn
	r0RzPRy8jQpGO1h5Gq1g3qRkAZfkl6zpMAvSUYRKQlk3gslK9gOrYXNzT4UG
	xzRuBccgiDwDaaV/jWYnD66t2VlGdzQ7c5BQCk3ljRqVvF+v8FsuzrjX+8tf
	/sJhhuESzhr0T+/jB1DHPswWEBzYgnhq/3B02HsL6U1hVxg2I32dIly9V6Kp
	hxeYfRwy2T6t3RP1tv3DwNwFbq930zOmn4D3+2Oou4ePHn83oCd/qiMOpOLp
	Ue+WIN8BvoO37Tx9AcrW0m6Y08ZjmIIMT58t97Hpu5BMgAKeotyHNT/MZ0O1
	5gf0DlkD9NIf8hpnydJmh0vIYzUQIoNhobNV6/0hOvOHB06XggamOI3SPD6Q
	l5OM3Popr7WvLso+Y25/Wc7L/Wgy5XE6G4ZhMnzXoSUe/GvnRRrf+q/5/bsn
	T58d9P/NHcFbcI8YTi0MeA54EBDrZMOClJC551xpNSRhXZUaUXO+LxhBcTi4
	07VyqwSOAHNEg5MBOQMU2vUjGi820L3uBESGRDEkZrXOSU2SIZ9TpNnjT2V6
	GbqEUJf6s8o8j1wW4SX+zS7JPbaFDd9zZlSVQ0zBMFw5a1nDA6z8aCw0b8xu
	GcSBE0J+Iw2YzsW6YouL16IIUEbyVTDivP0yWnqfSr2Br5INDmkd0aD7aQmH
	u7hfeRxzgvQeHY0eMoMDllnCHHPDxNef5mleEFFvbJrmawrV3n4F5x8dmc8Z
	JpvSL2R7KVv/7aQAJSeufHh5yIp+SwQU3rZPxPLgN4SDxTQgPmyz3U2HC0NB
	sawxFSgnopRPwo4PqdC5LbaYF7jNWb3Se/f2Ce/tEbeDb1/3/rywsOYG5j4Y
	/j5ZbfcnaW3v/9rqesz7crodOIKvXsKQjgWRq4kTUiyrbu+0shZUTDYcMWDj
	ryjIFyDR6eyKsusQ2AjeXHOKYq7BhKTHS7ucULCCPWNR3C6OQTZcP4hjt6z8
	pCxrJxAcEmhQmpPkC6MaLLZ8mIvp5H7pQ9viL6pZ8FEmUkvC5WPgzarkAIjH
	H0+bcGdplvDvEoqs+riQoEJ0UrmIVCaxSCDEciwBuw1MuibOxo6c919w7nUx
	JyDdTia2cZe2Y3cuZC0LgHTLRP0jKA5CiotmQtxW00W/deClU38i33RbcIqS
	Em48o5RGieXn9reMVmYNCSJhPPESfFiz12PnEhZhEEkk9MH8UZjj0My6S2oo
	2uwVBzrUHfcxyTiJGRS25jmgqI4/m6FEViTgREMygA+2whaPw8DFHlv+98x7
	pkv1Z7uGq7dZhXrL264Pr5QsOoMtEwJ5lhMsRG/6HjvGkX4DUYJHakE0R7oV
	xzirUDWT4mKMMMUI+7DnQZb+PMs1CJ+M7Ij1GQlrWnNN/jaRfZJhEULOLJxi
	EQkiJ1bca6KxEaHinkpnbJf+qmmuzwL2FRaSEE7IwhJyZH+drQiNwApNdKyP
	ttJ85dMjvD8XvdeladYH0aziWHiZp7VEOrGrzLKCKjZ7EkNqzws8r4pkiZ+D
	EGYTScNWmk0RQhQXAzaw5IRouyWBFquH1edE0ngCM+WSsh0a7+CT5IAr4YdF
	E5hao9QS29L4jmi+PvG86MC+4bSu3aO4hEOe+MtG/UVs6or85E4Qzfk2TSK1
	iwEHgci+dr5qb2Tegl+ubDEI0lONh0p5z5yiylOONTWw2daOMXmWSpZKxAWE
	ADvtAjRvJMjDsXS/sikFxUsHHo+nSMqkns85qpfnKTtpHK/fc2em9KAkV3L8
	KOWEvEAi8pBp5Aon5n/UqLXDF9uZpb4DulmxIuBvTlg85sSBQ4+gL1xLbcSo
	lkTKrHZqMtZAHeejhMvAcFmcAp5pDuN5WgGZEFHkSHOqzp9g2U2eKduSDe3i
	ZGVjOMEJ94ZiXsz3Z3m+P4kK8j36oi3vGrlO4jmsLTiFfTPJQZUqo132RNEM
	DRqlDnfh5gMW7+u8Q6W6vh6mPwPGBgskn1ihfKdl16zZ1YNf3VZ3oa/a4tZL
	tFOX4QADHAsNUVz3TnUdTVjk6LG7aG3iqVGIXXWwIwG8p3gIaYZsBHpbdWuS
	TdNaw1+zGihaRcC/S23tsxrm49zT1EdLyqi2E7EkEWnBOssGjGr5IqJEqmjO
	74vEAdFfHP8IAR2GoSmWlyUwntLNVi5MLANxa3qYa6yT/y5A/eDo4OhwePBs
	ePhk/KGuPsze1dNLdXMdPwVwui0JctjeotwYa/EdWe6JFZ7DWQmL4UG+lOih
	DxIr8fGOGVuZoriqC9vBigQ2yVjxuWSfbKV3Ie6vJB2Bg6Q8dpxzODUSGcUn
	reuVwWZIzCWlRJO3yxBocjaNcSrRJavOmAxBSl6wZ0n2WbRyScN1XqexC/ia
	ElxKBR5z9mpN+8wHYgGKNqaCDTlCTLJTPQix1iRopf5CXpxgDgZLIqbOOJC4
	MJkH8skZCO75lomQ1fIgTPjbrRgzpWboWSN9D0k9af68crQA1BQJtINLi8uG
	kjAq4dxy3eNoJ3x85o2qLyXYiQNIyrzYfE+kFcYmtqD1KS1NssFaTcLFnS4d
	mR9lA3nXrGEXIZxSCTSaViRxu7m8nE2QQrM3zrQXuFy1gvoiakkGZSqMIY16
	SiJmYslMLRttNDISNi8t8AhSGbqiDdFKGkaf1QUnm6d4mVIWhZ1TxZbG9bE1
	YLsx41ymnbcrO1XqYAMAnLSkRMTaeQtytFQs0cW0nv3c4dKsuUKCchIVOxhs
	xgqhxk54kn7NJBrOgVtYgJyzh9jbExGtJodGPgI3MWF7oISToS4LMSwjO+Bj
	PdutY2BFJ2h2u+/Sj7e0OaxBpjZ98La2PP0qY5srggZbmdV6yRZvmxVc5Pq0
	Ci08wZrkQwIuwhHdyVNwz6459U80QXZu6gr5WqZmk0h2eN2RUO4w/dHoULyy
	EBO6ccKEcqicHxuHrD41W0Hw1FyutV7krEzYtKmziE+GvDu8puViXjZvZcJa
	xrxuKa4Zhnw2S4lo05yqIqJ0AyLZc8fpohc39+STO1D3/KtOtHOU9noFN0Ow
	2y5C+Rqp51aWhdpSj3xrTtbNYBKTBORsnBPQrghIBET79MGDC8Yb+EsrRBqz
	PeSQUBoEJLeKCufcdVBDBxhM8H0YkKUT5EhsWSeVVDtxIQ3cDtajZOCROKEa
	QKLeCVfHcG1BGyY+Kx/Xxmm5z+68mt/+Cod3l6O7q85m68BcbUe4vtp5gd8V
	TZwd102NuXCa2HEzCwOBlBTxNRXMnTpriUM0Uo9wh1myIxng64x8seCi4OAM
	iTgpLrmb110UZovXHztu/8LemVW7+4fYZwuglPodMVbDGqWupRNKNjogquiY
	MORk8LFtqVKvKbqTPBGx2Sqi6V3dE3OGd0cbgP/fJf2buqQtXH+TXxrksP7G
	jmkD4Ld4ps1b/6uuaTPt38w9dUs0LipFU0+c0PZx1Zt7XpAH0VMJffoeBFjI
	x38QiR9/ScIJOcRxopkMDa8qOgrb0ZNBtdN26p7UYNEtIfXjxfHzeREQPKuT
	QClR/bNPZ3bylU0dTAPsjpxjWzmdJ8skjYp0I0K+302k9B3kYY3hdrbGx/ed
	RHL1L+SHXSUxcY+UHzWSkXwEeA0DQbCvDKM0rtGki+M4Dm5qARfle0jTs1gs
	1fVR+691fOz/SMyaa9y6uGzKm+JcqpumOWTzn+33Yu1wtKPs5jFyY6/Y02eL
	UMk1oI5QxbWDACrBvbPcgDLoeMjc/MFlLuSES9WTVlpRpxRJXSrQTsmPushD
	JqTlmrJPpwjDWtG9QSCGguIyLktXdJ+Rs1jUKevhJptxNHpIB8Dl/Ddjx8cv
	+vfOLob0Sv9WCpukzQc7PLNrn924YPSRqSo/3jZZL1cszeCEdWtBAb+YOb70
	IHLVbIBcUD8I4zNh6TjPxyHiyca41TVS0WHUHywVAPuOCK0JhHqC0xNJp0rg
	5q7D8jgzz3N20Z2rF7F+tRVRcWpn/LKYNEtLPlBSLssd1Zk0FTeXdCPTzsJg
	AFIuTGvrze/VTh40MEWulBJWPZHQnDN1hUsjNRaY+pr4jSrgyLu26WyEg5Tw
	FHspXXyVDfU4aqTIkpV0nSuToNnP1cnnlEvj5FMM5k7/H2SabNf4Fkl5KbWD
	lDunY6yqaHpprkChxDGTTfNTGzuyOzBoY0oKAak3TmfRFGtWIP6ND3v47KtP
	fHmqUymilu5qlTK6Sdo4dW6km4G7e6jJivVdzekNpQ5ATC03UhwO7yvJOtWQ
	Lf0Rmf4aGONCFPJF4FZqWLbRI4lILdiuG9CLT1gNYHySoRJ9oUUlyQKeo1jf
	x88XYQEEEcbQOYnwjEm9URAl3Qy61ZqCFM5PRuJJhVzpiny5fcyzMxfRqfAS
	licHgrzTjVNAI7OLZ+h4OePb6Sbj/GTFoQnsABhJSo5jEjX3uYBa0mKq7LpN
	SgNXa1pYbHkadF7E+RIn1ahVfYE9YYp7RUk82JEsh6bwDQe7Cg6ZWcPCWG4i
	cbk0fN/p74RhkKY6vVuUzu1HIkG5jNpbrj6sKZu4M1bi/aezjixoW1Wkdx0i
	x73e4chEQXwDnyS9NwiKIO/MT/aO+G0u0Hd11kFTUFMVAlQ/oEqMS4lRScit
	93C0O6DKjn+liQxfCj/6FVtRDluCg+qI0sdPtio2w2OXLBbmUZxvx5kPRtCj
	FGtOshZDTJMCKFP7FpAcB40zHnsa1fDZhrzbENjOzzLGmFvJKlvk626qogkH
	HN91oK2d7zCDVb7tNp67wisLTEaRDxyz3FANnVTa3dwETc6UyCdxKorTi1R1
	qbnlNIj73rW105l2KG0DH/k6JPFAvIWliMZxFM4DgBpnef3g+N3Ht8eBy0yt
	380B/8BMwlaATjLNlzhjcpEXETXY0sIcJ9GJXp/+eHpBlLJrIq1C+vc+jLnc
	y0SNurTLj12sJG/CZRRE2gsccoWIy5wK24KIY6vZnKsVxKviQ9t2xjd5zXhb
	1V6ahkYcjmFDTk6eceQS3LjiKB8kPbxKelmjAmo9eJHky3gopMpxkNBLMg9o
	UueMMPrYXWp2V4j1puHWJZkiTAdaEy2EwMCrQhHV1FJaXXnu8mJZq5aTZWWr
	A44NRa9zJyR0xeyk94MQiqKPHY4QGSxNsm6UzjOTO9mhXFSh0xSM70RK3aVb
	nrswyAHAiKatzBehS48vW8Ph6mmeXzb1XtIISPQYNAVKW0PmcDd07SxeMknD
	cE2JGQbNd9BRFRLXsYLbrrAbiajR4k0/I79M6WM+IxlNLln3BfaH4OxJM2rT
	jMDqvFEx0uzmA84TtZoFMNd3STOUEtiVsHyyFGJqOw++NWynHnH8uJYsV6NK
	qL0r57ooiI61jlraSK8yIVGcVM7Da4JjynufGPHc8dz1n/yZ7GxlDWsqGdjw
	9eZsZ+w5UVMQKeEYmnTIkLdUAMVnOBWIp0sqtuOz0lD/KgfLbBrLwU+Nz+ct
	kD5p09BApaVejNHIuUej75oiSEs1UOIfq/UiVYEQR3i9on5w5xa7Nm/aSJ1x
	vhkiZQJ/YMD4pdrBhk67aeikdIJjRweV5r2JuEDA/wLLMi+8aBjsFBgD7R9c
	pfmG3mskCVd1NZ5doWdLlDfq4MpRdBlQhopZ12EiJDuABLRkAHkOoQYyqiSg
	un32LqRWNW7ak9/tSYSZBa/GZEu9dIIMDiE655yR1nf5RDIVk+smvpjA+OfA
	YlSSg8gQ73NVt4s2sYN4r++9VkdQYU+glKhxFJDC4wqRK6jgalSJm3Zg84Th
	kOTAbCogqQGNaidgff5GSJ9va/nlXyV7sqsu4Zd/o6FyMQeNYysy7Afdld3k
	lz5ROchSvI+ugKC5mPtbPlYptbidIEXtCvYcwnR2tdJpKvbIdnC8s/v1Le5J
	awlzQPD8G0/vJaPJm3OZ64GA8qCAabHrRER83TNBwSJEFv/dLa8cM5Qs9ENh
	NdgqewxPMvipOTbaNR/AuSD7FZD9q+dztn/cxvLNzT/QfU+3LjsXQqFN/nzf
	zu2thvfr0vV1h6QxaDXKRO1MF9UQZHlokDYJ4Ynd5C5griS3I58vyaAWbEnZ
	RNJVb4XmntaARK5vZzdSVosiKp1HyCHd2Fd09sG7sOehS4WxHx08EqkHwzTP
	wo5mqDaSHxPr0vVi6pF54DK9jftJJZk+BOIZ4MsN1nxJQWoJ1MwLFDLRpDwE
	a7Gzs6uU2GkE2DeuwFqDojvOOnHtBtJrLQW6HjnyvpQSE3hZJWGQzV2pBJJx
	HPFQo5lcs2QKpHSgXMpjCt+IBQc4xDyi+Opd8bSbe3eF03xv0p3RT0FAO3it
	pQ6ucaQJ812RIxSH3c1S2sK1RC5w5irC3CqwXRdiBmtYJHBe8FsVdHVQ51cm
	63L2mBTVtKgxIY0mdZCUl74YA36ZVI61an6d3T6RmoY8qVyoe0n2TOIKhTYQ
	P8uBi6a5hKw+9XoiuYqmHESScg/XisXDAE9QddWUIIs/2y5saSXA28WHPnC1
	1N2045cON81dGyWHPuN6uQqsABfc3I7quugfE9NUiI8UcEnuOCfkgqaaJivd
	gUMK1ek+jID1dxe9ATQxk9Qebe3dA6xux5ZlLTFoWCxUAOGvEuFImlQoAkqK
	fVI3EzsBE1utrab1q3XOV/YkRZNuhISZ2thqWyZzIginaIKirdnEMWr7puEN
	NHtbxV4k011J2O4dZXJRDfmyTckY3+YTlIrdVeblb63Q238GEK1R7JoXqet9
	Bot1Df5Tw/YqKbByOWWzEGYzR57hk19aCVJfZpCQQKLereWqbkKIwws/gt4F
	yfKcHp8ddySQl8n1KnZ9Ul/ob5b85V0XkRQtc1TJpP+ee6LZGeo35g2HfmYu
	Xxj0qTdqQruUeJItzyicKyqDXhjOfzVusN6/lK/qVHo6tWu1pTd8XEjsHk6K
	0dVj5Jkw5tiF1yvx/C1mH12S4eZecO+et5rUV9JqqlKLr/3dhK05tcFMLvbT
	UsrWlrXTyN2cUYhznm12M1TSXP1U2WtvlLQMOXcFCwfIAOQVzy/tntyceY8q
	sU7G5v4v9w3HhdZFJHEhwhVdjPD0ybMj6S/9e9l72LEZoIRNV76ocP/o4Ohg
	eHi0r+O5G9W3bh5nNC1dt9BU5bAW1nHaExo+W/G9SRW4q2lm1XGus9K/J5VZ
	vmmyL7KNfoEGHnrjphkQuBIM3lfUcf3SayUopelSez79Rn8Vsq2Fv6qI84tr
	q6DfsXi3lbW7+sUuyfhL739ed92suISZsKz5FoKDg+ZpdK1PHz971tqMb5H9
	dkx+ZfHkL71fA74FUHAvwP8R2X1FASEX+EWsuJz3vuFLj37pubLtljU5C6vq
	YrfjsDUcMqItCf0NgveCAga5qVHvBuXkGG+BnOfwtkE1cPguw64x3uTJNMjr
	XAKn5ujqEWj+a7Vr3J2jkpQi+RrcharytVN4kWjHCpsf18NsPiS7EwayboN2
	75wKTjisKLkIPfeCDjIb083K42I2HZP86vdouKQiXvjbi+mZ29kLOW0rhpp/
	7NvBHzS/SSgm+O/GXJfxGNKfCOP2t76T+x+CV9iZ7L6itam7X9ESg295RSVC
	5xXXJH8qguWOd/0lCbs3ZfZ8czuenZUn8p48u2VUhs8dPkO0GZzO+Dc0c2vk
	f4hOdA3w/0EVCUUyoQI58xsFRUbs/UbIPAyAkWYXmnI9IT6PHZXtXJ6YHlwa
	ItrfaX6dwDXwUKlRKVfmwG6C/ZTofWxtCmX+7eSmOQnBnEvjdN7UX9Qb1uWU
	UjYG+SwpmmCpB7Fl7uHbCYXLbCRQuW4VCvxl3QVcFX5z6003L03w3mkv4u2m
	DpDvDRAB4nqluVAvTJepqxcwLVSP85udf66n3Kq/ni4SiDky2OlDYTOtDxDT
	rLlpoNW2oDM1jfBylyIducynAyjATQIhNveT++7aPr18jyEj0uDd7Wi1c9kx
	bSDjC5TYdKZNRqUGSMtdd4T81RfwAPd33Lzx/Lf4zVxRY0uevegfjg767O8S
	abzof754M3za/+3L3nMnrTA6K1/sEH8vwVzPiSBefuU1Ps+5j1FeI9H18ss3
	+WA4j6LxIrdeftttPs/1chWewYmiLWDptpHdt/w894WtPIOu9/LhwfN995me
	u1LPlyxsnie/vgIm/qrBfDeQDn6+36zz3B3zS3elR8OMHJmKhLa8Chto93ui
	hVBEb4acxljbtoTxvJRRPa75TW6E8x1lFHjYtDLedFmnz4tI4a4LGXr+ojSl
	E8Fl00fgISzlLt+uTneROKwovXlS/Omn5YQzG6Z0K7XX2LvrLkfmONsElQ47
	xJG7U6ErkmgS4O+yXqmZwtDI1XxuVRf+beyY8KbP7Zojxr87quDOBiK6Qu6/
	DvegpZbym7uLWEJjfM8uF4rK2LDmqDHu+NZxsexhjuEz39g508iTZkD8XOEe
	GAUPfr9H1Sws0rId22GfYGvbhNyNVf52MHNDayodI7YIV/PLa3QtKWG6b9Sg
	nxV4PaY7hwUURQnlBTMVwZTrk3foW3iRcZjiWofHxPGTapH7ujDuLosC5ct4
	g5xksi20ZIsdFxAIL6HdraRyt7dor+209i2v/hAkXPOZoejeNcK884E55I3w
	YK93CtVM/c3NZZSDoOTEdw3nddkQ19a9eTurUSTj19wQyDf4bVUIcRHJwkmY
	Tn2TxOXWWo3L0eGa77sTUnA2v+sR7cB193WoIqOEmdudRzbhr1RamgHZJYV+
	9OplZ9D4ij3Hza7AlaMyUpGx50yO5kbAnGdlSkybVmW5jLB106ka0w+2Q1Ot
	aw1v9xqzRpa4r9fTZ7sba+Q6+UGw0tRLV4ePrX1LAQqnotmxpAZ/b1HAGHju
	HkMFv7g7+keqhv2Tv+aOPvNNt/SZ/9k9fearb+ozW3f1mW+7rW/XfX3koDzf
	F6SqGhbCCbI5S42l8fF/ev2GfFT6/w7BwcddZSLN/T+XQf+KTwoq/Tb91o0K
	38HpLX75nslvR6WvCIpqwe+Sh1Bqt+zKuQlq5Es1H/eBBNXE7o4CX8gEmfZq
	1+Wq5uaeu4xV907XwbIephD9Moq71QI6nIsFwmivv6HASl+UBojZ3+ELdbfK
	ZXiCNk9CUMMc4tgKpSS3r/RqLJqKQ9QxT8KXId26W3hKvrQ2crW6qlGamx80
	2aUlFGGghfF0PKVgf2rjuVgzvZuxKBIbv+jPIERtX7PdrvVErn+gZIE2NWWX
	vZ9INqdzaqMv4ekMeuf1ZFLjURrBYon+WA967+mF42WNw6UBn/KNeUNBIWoG
	7p0UVCYYgcAKvBstzU/5AnwF11beez99Batr0PupTpOI6oZgml1K+xjW5qLM
	zKZpT8MtiVT+SDScMlH1HIeogu6/AeBK+ILaagAA


	</rfc>	</rfc>

End of changes. 68 change blocks.
	809 lines changed or deleted	399 lines changed or added
This html diff was produced by rfcdiff 1.48.