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

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.26 (Ruby 2.7.4) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dnsop-svcb-https-12" number="9460" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="SVCB and HTTPS RRs for DNS">Service binding Binding and parameter specification Parameter Specification via the DNS (DNS SVCB (SVCB and HTTPS RRs)</title> Resource Records)</title>

<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-latest"/> name="RFC" value="9460"/>
    <author initials="B." surname="Schwartz" fullname="Ben Schwartz">
      <organization>Google</organization>
      <organization>Meta Platforms, Inc.</organization>
      <address>
        <email>ietf@bemasc.net</email>
      </address>
    </author>
    <author initials="M." surname="Bishop" fullname="Mike Bishop">
      <organization>Akamai Technologies</organization>
      <address>
        <email>mbishop@evequefou.be</email>
      </address>
    </author>
    <author initials="E." surname="Nygren" fullname="Erik Nygren">
      <organization>Akamai Technologies</organization>
      <address>
        <email>erik+ietf@nygren.org</email>
      </address>
    </author>
    <date/>
    <area>General</area>
    <workgroup>DNSOP Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <date year="2023" month="November" />
    <area>ops</area>
    <workgroup>dnsop</workgroup>

    <keyword>multi-CDN</keyword>
    <keyword>HSTS</keyword>
    <keyword>ECH</keyword>
    <keyword>CNAME</keyword>
    <keyword>apex</keyword>
    <keyword>ALPN</keyword>
    <keyword>HTTP/3</keyword>
    <keyword>alias</keyword>
     <keyword>SvcParam</keyword>
     <keyword>AliasMode</keyword>
     <keyword>ServiceMode</keyword>

    <abstract>
      <t>This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR)
types to facilitate the lookup of information needed to make connections
to network services, such as for HTTP origins.  SVCB records
allow a service to be provided from multiple alternative endpoints,
each with associated parameters (such as transport protocol
configuration), and are extensible to support future uses
(such as keys for encrypting the TLS ClientHello).  They also
enable aliasing of apex domains, which is not possible with CNAME.
The HTTPS RR is a variation of SVCB for use with HTTP <xref target="HTTP"/>. (see RFC 9110, "HTTP Semantics").
By providing more information to the client before it attempts to
establish a connection, these records offer potential benefits to
both performance and privacy.</t>
      <t>TO BE REMOVED: This document is being collaborated on in Github at:
<eref target="https://github.com/MikeBishop/dns-alt-svc">https://github.com/MikeBishop/dns-alt-svc</eref>.
The most recent working version of the document, open issues, etc. should all be
available there.  The authors (gratefully) accept pull requests.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>The SVCB ("Service Binding") and HTTPS RRs resource records (RRs) provide clients with complete instructions
for access to a service.  This information enables improved
performance and privacy by avoiding transient connections to a suboptimal
default server, negotiating a preferred protocol, and providing relevant
public keys.</t>
      <t>For example, HTTP clients currently resolve only A and/or AAAA records for
the origin hostname, learning only its IP addresses.  If an HTTP client learns
more about the origin before connecting, it may be able to upgrade "http" URLs
to "https", enable HTTP/3 or Encrypted ClientHello <xref target="ECH"/>, target="I-D.ietf-tls-esni"/>,
or switch to an
operationally preferable endpoint.  It is highly desirable to minimize the
number of round-trips round trips and lookups required to
learn this additional information.</t>
      <t>The SVCB and HTTPS RRs also help when the operator of a service
wishes to delegate operational control to one or more other domains, e.g.
delegating e.g.,
aliasing the origin "https://example.com" to a service
operator endpoint at "svc.example.net".  While this case can sometimes
be handled by a CNAME, that does not cover all use-cases. use cases.  CNAME is also
inadequate when the service operator needs to provide a bound
collection of consistent configuration parameters through the DNS
(such as network location, protocol, and keying information).</t>
      <t>This document first describes the SVCB RR as a general-purpose resource
record RR that can be applied directly and efficiently to a wide range
of services (<xref target="svcb"/>).  It also describes the rules for defining other
SVCB-compatible RR types (<xref target="svcb-compatible"/>), starting with the HTTPS
RR type (<xref target="https"/>), which provides improved efficiency and convenience
with HTTP by avoiding the need for an Attrleaf label <xref target="Attrleaf"/> target="RFC8552"/>
(<xref target="httpsnames"/>).</t>
      <t>The SVCB RR has two modes: 1) "AliasMode", which simply delegates operational
control for a resource; resource and 2) "ServiceMode", which binds together
configuration information for a service endpoint.
ServiceMode provides additional key=value parameters
within each RDATA set.</t>
      <section anchor="goals-of-the-svcb-rr">
        <name>Goals of the SVCB RR</name> anchor="goals">
        <name>Goals</name>
        <t>The goal of the SVCB RR is to allow clients to resolve a single
additional DNS RR in a way that:</t>
        <ul spacing="normal">
          <li>Provides alternative endpoints that are authoritative for the service,
along with parameters associated with each of these endpoints.</li>
          <li>Does not assume that all alternative endpoints have the same parameters
or capabilities, or are even
operated by the same entity.  This is important, as DNS does not
provide any way to tie together multiple RRSets RRsets for the same name.
For example, if www.example.com "www.example.com" is a CNAME alias that switches
between one of three CDNs Content Delivery Networks (CDNs) or hosting environments, successive queries
for that name may return records that correspond to different environments.</li>
          <li>Enables CNAME-like functionality at a zone apex (such as
"example.com") for participating protocols, protocols and generally
enables delegation of extending operational authority for an origin within the
DNS a service identified
by a domain name to an other instances with alternate name.</li> names.</li>
        </ul>
        <t>Additional goals specific to HTTPS RRs and the HTTP use-cases use cases include:</t>
        <ul spacing="normal">
          <li>Connect
          <li>Connecting directly to HTTP/3 (QUIC transport)
alternative endpoints <xref target="HTTP3"/></li>
          <li>Support target="RFC9114"/>.</li>
          <li>Supporting non-default TCP and UDP ports</li>
          <li>Enable ports.</li>
          <li>Enabling SRV-like benefits (e.g. (e.g., apex delegation, aliasing, as mentioned above) for HTTP,
where SRV <xref target="SRV"/> target="RFC2782"/> has not been widely adopted</li>
          <li>Provide adopted.</li>
          <li>Providing an HSTS-like indication <xref target="HSTS"/> signaling that the "https" scheme should
          be used instead of "http" for all HTTP requests to this host and port port,
          similar to HTTP Strict Transport Security <xref
          target="RFC6797"/> (see
<xref target="hsts"/>).</li>
          <li>Enable
          <li>Enabling the conveyance of Encrypted ClientHello <xref target="ECH"/> keys <xref target="I-D.ietf-tls-esni"/> associated
with an alternative endpoint.</li>
        </ul>
      </section>
      <section anchor="overview-of-the-svcb-rr">
        <name>Overview of the SVCB RR</name>
        <t>This subsection briefly describes the SVCB RR with forward references to
the full exposition of each component.  (As mentioned above, discussed in <xref target="svcb-compatible"/>, this all
applies equally to the HTTPS RR RR, which shares
the same encoding, format, and high-level semantics.)</t>
        <t>The SVCB RR has two modes: 1) AliasMode (<xref target="alias-mode"/>), which aliases a name
to another name, name and 2) ServiceMode (<xref target="service-mode"/>), which provides connection
information bound to a service endpoint domain.  Placing both forms in a single
RR type allows clients to
fetch the relevant information with a single query (<xref target="svcb-names"/>).</t>
        <t>The SVCB RR has two required fields and one optional field.  The fields are:</t>
        <ol
        <dl spacing="normal" type="1"><li>SvcPriority newline="false"><dt>SvcPriority (<xref target="pri"/>): The target="pri"/>):</dt><dd>The priority of this record (relative to others,
with lower values preferred).  A value of 0 indicates AliasMode.</li>
          <li>TargetName: The AliasMode.</dd>
          <dt>TargetName:</dt><dd>The domain name of either the alias target (for
AliasMode) or the alternative endpoint (for ServiceMode).</li>
          <li>SvcParams (optional): A ServiceMode).</dd>
          <dt>SvcParams (optional):</dt><dd>A list of key=value pairs
describing the alternative endpoint at
TargetName (only used in ServiceMode and otherwise ignored).
Described
SvcParams are described in <xref target="presentation"/>.</li>
        </ol> target="presentation"/>.</dd>
</dl>
        <t>Cooperating DNS recursive resolvers will perform subsequent record
resolution (for SVCB, A, and AAAA records) and return them in the
Additional Section section of the response (<xref target="recursive-behavior"/>).  Clients either use responses
included in the additional Additional section returned by the recursive resolver
or perform necessary SVCB, A, and AAAA record resolutions (<xref target="client-behavior"/>).  DNS
authoritative servers can attach in-bailiwick SVCB, A, AAAA, and CNAME
records in the Additional Section section to responses for a SVCB query (<xref target="authoritative-behavior"/>).</t>
        <t>In ServiceMode, the SvcParams of the SVCB RR
provide an extensible data model for describing alternative
endpoints that are authoritative for a service, along with
parameters associated with each of these alternative endpoints (<xref target="keys"/>).</t>
        <t>For HTTP use-cases, use cases, the HTTPS RR (<xref target="https"/>) enables many of the benefits of Alt-Svc
<xref target="AltSvc"/> target="RFC7838"/>
without waiting for a full HTTP connection initiation (multiple roundtrips) round trips)
before learning of the preferred alternative,
and without necessarily revealing the user's
intended destination to all entities along the network path.</t>
      </section>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>Our terminology
        <t>Terminology in this document is based on the common case where the SVCB record is used to
access a resource identified by a URI whose <tt>authority</tt> field contains a DNS
hostname as the <tt>host</tt>.</t>
        <ul spacing="normal">
          <li>The "service" is the information source identified by the <tt>authority</tt> and
<tt>scheme</tt> of the URI, capable of providing access to the resource.  For "https"
URIs, the "service" corresponds to an "origin" <xref target="RFC6454"/>.</li>
          <li>The "service name" is the <tt>host</tt> portion of the authority.</li>
          <li>The "authority endpoint" is the authority's hostname and a port number implied
by the scheme or specified in the URI.</li>
          <li>An "alternative endpoint" is a hostname, port number, and other associated
instructions to the client on how to reach an instance of a service.</li>
        </ul>
        <t>Additional DNS terminology intends to be consistent
with <xref target="DNSTerm"/>.</t> target="RFC8499"/>.</t>
        <t>SVCB is a contraction of "service binding".  The SVCB RR, HTTPS RR,
and future RR types that share SVCB's formats and registry are
collectively known as SVCB-compatible RR types.  The contraction "SVCB" is also
used to refer to this system as a whole.</t>
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="svcb">
      <name>The SVCB record type</name> Record Type</name>

      <t>The SVCB DNS resource record (RR) RR type (RR type 64)
is used to locate alternative endpoints for a service.</t>
      <t>The algorithm for resolving SVCB records and associated
address records is specified in <xref target="client-behavior"/>.</t>

      <t>Other SVCB-compatible resource record RR types
can also be defined as-needed as needed (see <xref target="svcb-compatible"/>).  In particular, the
HTTPS RR (RR type 65) provides special handling
for the case of "https" origins as described in <xref target="https"/>.</t>
      <t>SVCB RRs are extensible by a list of SvcParams, which are pairs consisting of a
SvcParamKey and a SvcParamValue. Each SvcParamKey has a presentation name and a
registered number. Values are in a format specific to the SvcParamKey.  Each
SvcParam has a specified presentation format (used in zone files) and
wire encoding
(e.g., domain names, binary data, or numeric values). The initial SvcParamKeys
and their formats are defined in <xref target="keys"/>.</t>
      <section anchor="presentation">
        <name>Zone file presentation format</name>
        <name>Zone-File Presentation Format</name>
        <t>The presentation format <tt>&lt;RDATA&gt;</tt> of the record (<xref section="5.1" sectionFormat="comma" target="RFC1035"/>) has
the form:</t>
        <artwork><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
SvcPriority TargetName SvcParams
]]></artwork>
]]></sourcecode>
        <t>The SVCB record is defined specifically within
the Internet ("IN") Class (<xref section="3.2.4" sectionFormat="comma" target="RFC1035"/>).</t>
        <t>SvcPriority is a number in the range 0-65535,
TargetName is a <tt>&lt;domain-name&gt;</tt> (<xref section="5.1" sectionFormat="comma" target="RFC1035"/>),
and the SvcParams are a whitespace-separated list, list with each SvcParam
consisting of a SvcParamKey=SvcParamValue pair or a standalone SvcParamKey.
SvcParamKeys are subject to registered by IANA control (<xref target="svcparamregistry"/>).</t>
        <t>Each SvcParamKey SHALL <bcp14>SHALL</bcp14> appear at most once in the SvcParams.
In presentation format, SvcParamKeys are lower-case lowercase alphanumeric strings.
Key names contain 1-63 characters from the ranges "a"-"z", "0"-"9", and "-".
In ABNF <xref target="RFC5234"/>,</t>
        <artwork><![CDATA[
<sourcecode name="" type="abnf"><![CDATA[
alpha-lc      = %x61-7A   ; a-z
SvcParamKey   = 1*63(alpha-lc / DIGIT / "-")
SvcParam      = SvcParamKey ["=" SvcParamValue]
SvcParamValue = char-string ; See Appendix A A.
value         = *OCTET ; Value before key-specific parsing
]]></artwork>
]]></sourcecode>
        <t>The SvcParamValue is parsed using the
character-string decoding algorithm (<xref target="decoding"/>), producing a <tt>value</tt>.
The <tt>value</tt> is then validated and converted into wire-format wire format in a manner
specific to each key.</t>
        <t>When the optional "=" and SvcParamValue are omitted, the <tt>value</tt> is
interpreted as empty.</t>
        <t>Arbitrary keys can be represented using the unknown-key presentation format
"keyNNNNN" where NNNNN is the numeric
value of the key type without leading zeros.
A SvcParam in this form SHALL <bcp14>SHALL</bcp14> be parsed as specified above, and
the decoded <tt>value</tt> SHALL <bcp14>SHALL</bcp14> be used as its wire format wire-format encoding.</t>
        <t>For some SvcParamKeys, the <tt>value</tt> corresponds to a list or set of
items.  Presentation formats for such keys SHOULD <bcp14>SHOULD</bcp14> use a comma-separated list
(<xref target="value-list"/>).</t>
        <t>SvcParams in presentation format MAY <bcp14>MAY</bcp14> appear in any order, but keys MUST NOT <bcp14>MUST NOT</bcp14> be
repeated.</t>
      </section>
      <section anchor="rdata-wire-format">
        <name>RDATA wire format</name> Wire Format</name>
        <t>The RDATA for the SVCB RR consists of:</t>
        <ul spacing="normal">
          <li>a 2-octet field for SvcPriority as an integer in network
byte order.</li>
          <li>the uncompressed, fully-qualified fully qualified TargetName, represented as
a sequence of length-prefixed labels as in per <xref section="3.1" sectionFormat="of" target="RFC1035"/>.</li>
          <li>the SvcParams, consuming the remainder of the record
(so smaller than 65535 octets and constrained by the RDATA
and DNS message sizes).</li>
        </ul>
        <t>When the list of SvcParams is non-empty, it contains a series of
SvcParamKey=SvcParamValue pairs, represented as:</t>
        <ul spacing="normal">
          <li>a 2-octet field containing the SvcParamKey as an
integer in network byte order.  (See <xref target="iana-keys"/> for the defined values.)</li>
          <li>a 2-octet field containing the length of the SvcParamValue
as an integer between 0 and 65535 in network byte order.</li>
          <li>an octet string of this length whose contents are the SvcParamValue in a
format determined by the SvcParamKey.</li>
        </ul>
        <t>SvcParamKeys SHALL <bcp14>SHALL</bcp14> appear in increasing numeric order.</t>
        <t>Clients MUST <bcp14>MUST</bcp14> consider an RR malformed if:</t>
        <ul spacing="normal">
          <li>the end of the RDATA occurs within a SvcParam.</li>
          <li>SvcParamKeys are not in strictly increasing numeric order.</li>
          <li>the SvcParamValue for an a SvcParamKey does not have the expected format.</li>
        </ul>
        <t>Note that the second condition implies that there are no duplicate
SvcParamKeys.</t>
        <t>If any RRs are malformed, the client MUST <bcp14>MUST</bcp14> reject the entire RRSet RRset and
fall back to non-SVCB connection establishment.</t>
      </section>
      <section anchor="svcb-names">
        <name>SVCB query names</name> Query Names</name>
        <t>When querying the SVCB RR, a service is translated into a QNAME by prepending
the service name with a label indicating the scheme, prefixed with an underscore,
resulting in a domain name like "_examplescheme.api.example.com.".  This
follows the Attrleaf naming pattern <xref target="Attrleaf"/>, target="RFC8552"/>, so the scheme MUST <bcp14>MUST</bcp14> be
registered appropriately with IANA (see <xref target="other-standards"/>).</t>
        <t>Protocol mapping documents MAY <bcp14>MAY</bcp14> specify additional underscore-prefixed labels
to be prepended.  For schemes that specify a port (<xref section="3.2.3" sectionFormat="of" target="URI"/>), target="RFC3986"/>), one reasonable possibility is to prepend the indicated port
number if a non-default port number is specified.  We term  This document terms this behavior
"Port Prefix Naming", Naming" and use uses it in the examples throughout this document.</t> throughout.</t>
        <t>See <xref target="httpsnames"/> for the information regarding HTTPS RR behavior.</t>
        <t>When a prior CNAME or SVCB record has aliased to
a SVCB record, each RR SHALL <bcp14>SHALL</bcp14> be returned under its own owner name, as in
ordinary CNAME processing (<xref section="3.6.2" sectionFormat="comma" target="RFC1034"/>).  For details, see
the recommendations regarding aliases for clients (<xref target="client-behavior"/>),
servers (<xref target="server-behavior"/>), and zones (<xref target="zone-structures"/>).</t>
        <t>Note that none of these forms alter the origin or authority for validation
purposes.
For example, TLS clients MUST <bcp14>MUST</bcp14> continue to validate TLS certificates
for the original service name.</t>
        <t>As an example, the owner of example.com "example.com" could publish this record:</t>
        <artwork><![CDATA[
        <sourcecode type="dns-rr"><![CDATA[
_8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.
]]></artwork>
        <t>to
]]></sourcecode>
        <t>This record would indicate that "foo://api.example.com:8443" is aliased to "svc4.example.net".
The owner of example.net, "example.net", in turn, could publish this record:</t>
        <artwork><![CDATA[
        <sourcecode type="dns-rr"><![CDATA[
svc4.example.net.  7200  IN SVCB 3 svc4.example.net. (
    alpn="bar" port="8004" )
]]></artwork>
        <t>to
]]></sourcecode>
        <t>This record would indicate that these services are served on port number 8004,
which supports the protocol "bar" and its associated transport in
addition to the default transport protocol for "foo://".</t>
        <t>(Parentheses are used to ignore a line break in DNS zone file zone-file presentation
format (<xref
format, per <xref section="5.1" sectionFormat="comma" target="RFC1035"/>).)</t> sectionFormat="of" target="RFC1035"/>.)</t>
      </section>
      <section anchor="interpretation">
        <name>Interpretation</name>
        <section anchor="pri">
          <name>SvcPriority</name>
          <t>When SvcPriority is 0 0, the SVCB record is in AliasMode (<xref target="alias-mode"/>).
Otherwise, it is in ServiceMode (<xref target="service-mode"/>).</t>
          <t>Within a SVCB RRSet, RRset,
all RRs SHOULD <bcp14>SHOULD</bcp14> have the same Mode. mode.
If an RRSet RRset contains a record in AliasMode, the recipient MUST <bcp14>MUST</bcp14> ignore
any ServiceMode records in the set.</t>
          <t>RRSets
          <t>RRsets are explicitly unordered collections, so the
SvcPriority field is used to impose an ordering on SVCB RRs.
A smaller SvcPriority indicates that the domain owner recommends the use of this
record over ServiceMode RRs with a larger SvcPriority value.</t>
          <t>When receiving an RRSet RRset containing multiple SVCB records with the
same SvcPriority value, clients SHOULD <bcp14>SHOULD</bcp14> apply a random shuffle within a
priority level to the records before using them, to ensure uniform
load-balancing.</t>
load balancing.</t>
        </section>
        <section anchor="alias-mode">
          <name>AliasMode</name>
          <t>In AliasMode, the SVCB record aliases a service to a
TargetName.  SVCB RRSets SHOULD RRsets <bcp14>SHOULD</bcp14> only have a single resource
record RR in AliasMode.  If multiple AliasMode RRs are present, clients or recursive
resolvers SHOULD <bcp14>SHOULD</bcp14> pick one at random.</t> random.
</t>
          <t>The primary purpose of AliasMode is to allow aliasing at the zone
apex, where CNAME is not allowed (see e.g. (see, for example, <xref section="2.4" sectionFormat="comma" target="RFC1912"/>).
In AliasMode, the TargetName will
be the name of a domain that resolves to SVCB,
AAAA, and/or A records.  (See <xref target="svcb-compatible"/> for aliasing of SVCB-compatible RR types.)
Unlike CNAME, AliasMode records do not affect the resolution of other RR
types,
types and apply only to a specific service, not an entire domain name.</t>
          <t>The AliasMode TargetName SHOULD NOT <bcp14>SHOULD NOT</bcp14> be equal
to the owner name, as this would result in a loop.
In AliasMode, recipients MUST <bcp14>MUST</bcp14> ignore any SvcParams that are present.
Zone-file parsers MAY <bcp14>MAY</bcp14> emit a warning if an AliasMode record has SvcParams.
The use of SvcParams in AliasMode records is currently not defined, but a
future specification could extend AliasMode records to include SvcParams.</t>
          <t>For example, the operator of foo://example.com:8080 "foo://example.com:8080" could
point requests to a service operating at foosvc.example.net "foosvc.example.net"
by publishing:</t>
          <artwork><![CDATA[
          <sourcecode type="dns-rr"><![CDATA[
_8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net.
]]></artwork>
]]></sourcecode>
          <t>Using AliasMode maintains a separation of concerns: the owner of
foosvc.example.net
"foosvc.example.net" can add or remove ServiceMode SVCB records without
requiring a corresponding change to example.com. "example.com".  Note that if
foosvc.example.net
"foosvc.example.net" promises to always publish a SVCB record, this AliasMode
record can be replaced by a CNAME at the same owner name, which would likely
improve performance.</t> name.</t>
          <t>AliasMode is especially useful for SVCB-compatible RR types that do not
require an underscore prefix, such as the HTTPS RR type.  For example,
the operator of https://example.com "https://example.com" could point requests to a server
at svc.example.net "svc.example.net" by publishing this record at the zone apex:</t>
          <artwork><![CDATA[
          <sourcecode type="dns-rr"><![CDATA[
example.com. 3600 IN HTTPS 0 svc.example.net.
]]></artwork>
]]></sourcecode>
          <t>Note that the SVCB record's owner name MAY <bcp14>MAY</bcp14> be the canonical name
of a CNAME record, and the TargetName MAY <bcp14>MAY</bcp14> be the owner of a CNAME
record. Clients and recursive resolvers MUST <bcp14>MUST</bcp14> follow CNAMEs as normal.</t>
          <t>To avoid unbounded alias chains, clients and recursive resolvers MUST <bcp14>MUST</bcp14> impose a
limit on the total number of SVCB aliases they will follow for each resolution
request.  This limit MUST NOT <bcp14>MUST NOT</bcp14> be zero, i.e. i.e., implementations MUST <bcp14>MUST</bcp14> be able to
follow at least one AliasMode record.  The exact value of this limit
is left to implementations.</t>
          <t>Zones that require following multiple AliasMode records could encounter
compatibility and performance issues.</t>
          <t>As legacy clients will not know to use this record, service
operators will likely need to retain fallback AAAA and A records
alongside this SVCB record, although in a common case
the target of the SVCB record might offer better performance, and
therefore would be preferable for clients implementing this specification
to use.</t>
          <t>AliasMode records only apply to queries for the specific RR type.
For example, a SVCB record cannot alias to an HTTPS record,
nor vice-versa.</t> record or vice versa.</t>
        </section>
        <section anchor="service-mode">
          <name>ServiceMode</name>
          <t>In ServiceMode, the TargetName and SvcParams within each resource record RR
associate an alternative endpoint for the service with its connection
parameters.</t>
          <t>Each protocol scheme that uses SVCB MUST <bcp14>MUST</bcp14> define a protocol mapping that
explains how SvcParams are applied for connections of that scheme.
Unless specified otherwise by the
protocol mapping, clients MUST <bcp14>MUST</bcp14> ignore any SvcParam that they do
not recognize.</t>
          <t>Some SvcParams impose requirements on other SvcParams in the RR.  A
ServiceMode RR is called "self-consistent" if its SvcParams all comply with
each other's requirements.  Clients MUST <bcp14>MUST</bcp14> reject any RR whose recognized
SvcParams are not self-consistent, self-consistent and MAY <bcp14>MAY</bcp14> reject the entire RRSet. RRset.  To
help zone operators avoid this condition, zone-file implementations SHOULD <bcp14>SHOULD</bcp14>
enforce self-consistency as well.</t>
        </section>
      </section>
      <section anchor="dot">
        <name>Special handling Handling of "." in TargetName</name>
        <t>If TargetName has the value "." (represented in the wire format as a
zero-length label), special rules apply.</t>
        <section anchor="aliasdot">
          <name>AliasMode</name>
          <t>For AliasMode SVCB RRs, a TargetName of "." indicates that the service
is not available or does not exist.  This indication is advisory:
clients encountering this indication MAY <bcp14>MAY</bcp14> ignore it and attempt to connect
without the use of SVCB.</t>
        </section>
        <section anchor="servicemode">
          <name>ServiceMode</name>
          <t>For ServiceMode SVCB RRs, if TargetName has the value ".", then the
owner name of this record MUST <bcp14>MUST</bcp14> be used as the effective TargetName.
If the record has a wildcard owner name in the zone file, the recipient
SHALL
<bcp14>SHALL</bcp14> use the response's synthesized owner name as the effective TargetName.</t>
          <t>For
          <t>Here, for example, in the following example "svc2.example.net" is the effective TargetName:</t>
          <artwork><![CDATA[
          <sourcecode type="dns-rr"><![CDATA[
example.com.      7200  IN HTTPS 0 svc.example.net.
svc.example.net.  7200  IN CNAME svc2.example.net.
svc2.example.net. 7200  IN HTTPS 1 . port=8002
svc2.example.net. 300   IN A     192.0.2.2
svc2.example.net. 300   IN AAAA  2001:db8::2
]]></artwork>
]]></sourcecode>
        </section>
      </section>
    </section>
    <section anchor="client-behavior">
      <name>Client behavior</name> Behavior</name>
      <t>"SVCB resolution" is the process of enumerating and ordering the priority-ordered available endpoints
for a service, as performed by the client.  SVCB resolution is implemented as follows:</t>
      <ol spacing="normal" type="1"><li>Let $QNAME be the service name plus appropriate prefixes for the
scheme (see <xref target="svcb-names"/>).</li>
        <li>Issue a SVCB query for $QNAME.</li>
        <li>If an AliasMode SVCB record is returned for $QNAME (after following CNAMEs
as normal), set $QNAME to its TargetName (without
additional prefixes) and loop back to step Step 2,
subject to chain length limits and loop detection heuristics (see
<xref target="client-failures"/>).</li>
        <li>If one or more "compatible" (<xref target="mandatory"/>) ServiceMode records are returned,
these represent the alternative endpoints.</li> endpoints. Sort the records by ascending SvcPriority.</li>
        <li>Otherwise, SVCB resolution has failed, and the list of known available endpoints is
empty.</li>
      </ol>
      <t>This procedure does not rely on any recursive or authoritative DNS server to
comply with this specification or have any awareness of SVCB.</t>
      <t>A client is called "SVCB-optional" if it can connect without the use of
ServiceMode records, and "SVCB-reliant" otherwise. records; otherwise, it is called "SVCB-reliant".  Clients for pre-existing
protocols (e.g. (e.g., HTTP) SHALL <bcp14>SHALL</bcp14> implement SVCB-optional behavior (except as
noted in <xref target="client-failures"/> or when modified by future specifications).</t>
      <t>SVCB-optional clients SHOULD <bcp14>SHOULD</bcp14> issue in parallel any other DNS queries that might
be needed for connection establishment if the SVCB record is absent, in order to minimize delay
in that case and enable the optimizations discussed in <xref target="optimizations"/>.</t>
      <t>Once SVCB resolution has concluded, whether successful or not,
if at least one AliasMode record was processed,
SVCB-optional clients SHALL <bcp14>SHALL</bcp14> append to the priority list of endpoints an
endpoint consisting of the final value of $QNAME, the authority
endpoint's port number, and no SvcParams.  (This endpoint will be
attempted before falling back to non-SVCB connection modes.  This ensures that
SVCB-optional clients will make use of an AliasMode record whose TargetName has
A and/or AAAA records but no SVCB records.)</t>
      <t>The client proceeds with connection establishment using the resolved this list of
endpoints.  Clients SHOULD <bcp14>SHOULD</bcp14> try higher-priority alternatives first, with
fallback to lower-priority alternatives.  Clients resolve AAAA and/or A
records for the selected TargetName, TargetName and MAY <bcp14>MAY</bcp14> choose between them using an
approach such as Happy Eyeballs <xref target="HappyEyeballsV2"/>.</t> target="RFC8305"/>.</t>
      <t>If the client is SVCB-optional, SVCB-optional and connecting using this list of endpoints has
failed, the client now attempts to use non-SVCB connection modes.</t>
      <t>Some important optimizations are discussed in <xref target="optimizations"/>
to avoid additional latency in comparison to ordinary AAAA/A lookups.</t>
      <section anchor="client-failures">
        <name>Handling resolution failures</name> Resolution Failures</name>
        <t>If DNS responses are cryptographically protected (e.g. (e.g., using DNSSEC or
TLS <xref target="DoT"/><xref target="DoH"/>), target="RFC7858"/> <xref target="RFC8484"/>) and SVCB resolution fails
due to an authentication error, SERVFAIL response, transport error, or
timeout, the client SHOULD <bcp14>SHOULD</bcp14> abandon its attempt to reach the service, even
if the client is SVCB-optional.  Otherwise, an active attacker
could mount a downgrade attack by denying the user access to the SvcParams.</t>
        <t>A SERVFAIL error can occur if the domain is DNSSEC-signed, the recursive
resolver is DNSSEC-validating, and the attacker is between the recursive
resolver and the authoritative DNS server.  A transport error or timeout can
occur if an active attacker between the client and the recursive resolver is
selectively dropping SVCB queries or responses, based on their size or
other observable patterns.</t>
        <t>If the client enforces DNSSEC validation on A/AAAA responses, it SHOULD <bcp14>SHOULD</bcp14>
apply the same validation policy to SVCB.  Otherwise, an attacker could
defeat the A/AAAA protection by forging SVCB responses that direct the
client to other IP addresses.</t>
        <t>If DNS responses are not cryptographically protected, clients MAY <bcp14>MAY</bcp14> treat
SVCB resolution failure as fatal or nonfatal.</t>
        <t>If the client is unable to complete SVCB resolution due to its chain length
limit, the client MUST <bcp14>MUST</bcp14> fall back to the authority endpoint, as if the
origin's
service's SVCB record did not exist.</t>
      </section>
      <section anchor="clients-using-a-proxy">
        <name>Clients using Using a Proxy</name>
        <t>Clients using a domain-oriented transport proxy like HTTP CONNECT
(<xref section="4.3.6" sectionFormat="comma" target="RFC7231"/>) or SOCKS5 (<xref target="RFC1928"/>) <xref target="RFC1928"/> have the option to
use of
using named destinations, in which case the client does not perform
any A or AAAA queries for destination domains.  If the client is configured
to use named
destinations with a proxy that does not provide SVCB query capability
(e.g.
(e.g., through an affiliated DNS resolver), the client would have to perform
SVCB resolution separately, likely disclosing the destinations to additional parties than and not just the proxy.
Clients in this configuration SHOULD <bcp14>SHOULD</bcp14> arrange for a separate SVCB resolution
procedure with appropriate privacy properties.  If this is not possible,
SVCB-optional clients MUST <bcp14>MUST</bcp14> disable SVCB resolution entirely, and SVCB-reliant
clients MUST <bcp14>MUST</bcp14> treat the configuration as invalid.</t>
        <t>If the client does use SVCB and named destinations, the client SHOULD <bcp14>SHOULD</bcp14> follow
the standard SVCB resolution process, selecting the smallest-SvcPriority
option that is compatible with the client and the proxy.  When connecting
using a SVCB record, clients MUST <bcp14>MUST</bcp14> provide the final TargetName and port to the
proxy, which will perform any required A and AAAA lookups.</t>
        <t>This arrangement has several benefits:</t>
        <ul spacing="normal">
          <li>
            <t>Compared to disabling SVCB:
            </t>
            <ul spacing="normal">
              <li>It allows the client to use the SvcParams, if present, which are
only usable with a specific TargetName.  The SvcParams may
include information that enhances performance (e.g. alpn) (e.g., supported protocols) and privacy.</li>
              <li>It allows the a service to delegate the on an apex domain.</li> domain to use aliasing.</li>
            </ul>
          </li>
          <li>
            <t>Compared to providing the proxy with an IP address:
            </t>
            <ul spacing="normal">
              <li>It allows the proxy to select between IPv4 and IPv6 addresses for the
server according to its configuration.</li>
              <li>It ensures that the proxy receives addresses based on its network
geolocation, not the client's.</li>
              <li>It enables faster fallback for TCP destinations with multiple addresses
of the same family.</li>
            </ul>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="server-behavior">
      <name>DNS Server Behavior</name>
      <section anchor="authoritative-behavior">
        <name>Authoritative servers</name> Servers</name>
        <t>When replying to a SVCB query, authoritative DNS servers SHOULD <bcp14>SHOULD</bcp14> return
A, AAAA, and SVCB records in the Additional Section section for any TargetNames
that are in the zone.  If the zone is signed, the server SHOULD <bcp14>SHOULD</bcp14> also
include positive or negative DNSSEC responses for records authenticating the existence or nonexistence of these records
in the Additional section.</t>
        <t>See <xref target="ecs"/> for exceptions.</t>
      </section>
      <section anchor="recursive-behavior">
        <name>Recursive resolvers</name> Resolvers</name>
        <t>Whether the recursive resolver is aware of SVCB or not, the normal response
construction process (i.e. used for unknown RR type resolution under types <xref target="RFC3597"/>) target="RFC3597"/>
generates the Answer section of the response.
Recursive resolvers that are aware of SVCB SHOULD <bcp14>SHOULD</bcp14> help the client to
execute the procedure in <xref target="client-behavior"/> with minimum overall
latency by incorporating additional useful information into the
Additional section of the response as follows:</t> follows:
</t>
        <ol spacing="normal" type="1"><li>Incorporate the results of SVCB resolution.  If the recursive resolver's
local chain length limit (which may be different from the client's limit) has
been reached, terminate.</li>
          <li>
            <t>If any of the resolved SVCB records are in AliasMode, choose one of them
at random, and resolve SVCB, A, and AAAA records for its
TargetName.  </t>
            <ul spacing="normal">
              <li>If any SVCB records are resolved, go to step Step 1.</li>
              <li>Otherwise, incorporate the results of A and AAAA resolution, and
terminate.</li>
            </ul>
          </li>
          <li>All the resolved SVCB records are in ServiceMode.  Resolve A and AAAA
queries for each TargetName (or for the owner name if TargetName
is "."), incorporate all the results, and terminate.</li>
        </ol>
        <t>In this procedure, "resolve" means the resolver's ordinary recursive
resolution procedure, as if processing a query for that RRSet. RRset.
This includes following any aliases that the resolver would ordinarily
follow (e.g. (e.g., CNAME, DNAME <xref target="DNAME"/>). target="RFC6672"/>).  Errors or anomalies in
obtaining additional records MAY <bcp14>MAY</bcp14> cause this process to terminate, terminate but
MUST NOT
<bcp14>MUST NOT</bcp14> themselves cause the resolver to send a failure response.</t>
        <t>See <xref target="alias-mode"/> for additional safeguards for recursive resolvers
to implement to mitigate loops.</t>
        <t>See <xref target="incomplete-response"/> for possible optimizations of this procedure.</t>
        <section anchor="dns64">
          <name>DNS64</name>
          <t>DNS64 resolvers synthesize responses to AAAA queries for names that only
have an A record (<xref section="5.1.7" sectionFormat="of" target="RFC6147"/>).  SVCB-aware DNS64
resolvers SHOULD <bcp14>SHOULD</bcp14> apply the same synthesis logic when resolving AAAA
records for the TargetName for inclusion as Additionals in the Additional section (Step 2 in
<xref target="recursive-behavior"/>), target="recursive-behavior"/>) and MAY <bcp14>MAY</bcp14> omit the Additional A records.</t> records from this section.</t>
          <t>DNS64 resolvers MUST NOT <bcp14>MUST NOT</bcp14> extrapolate the AAAA synthesis logic to the IP
hints in the SvcParams (<xref target="svcparamkeys-iphints"/>).  Modifying the IP hints
would break DNSSEC validation for the SVCB record and would not improve
performance when the above recommendation is implemented.</t>
        </section>
      </section>
      <section anchor="general-requirements">
        <name>General requirements</name> Requirements</name>
        <t>Recursive resolvers MUST <bcp14>MUST</bcp14> be able to convey SVCB records with unrecognized
SvcParamKeys, and MAY treat
SvcParamKeys.  Resolvers <bcp14>MAY</bcp14> accomplish this by treating
the entire SvcParams portion of the record as opaque, even if the contents
are invalid.  Alternatively,  If a recognized SvcParamKey is followed by a value that is
invalid according to the SvcParam's specification, a recursive
resolvers MAY resolver
<bcp14>MAY</bcp14> report an error such as SERVFAIL to avoid instead of returning a
SvcParamValue that is invalid according to
the SvcParam's specification. record.
For complex value types whose interpretation might differ
between implementations or have additional future
allowed values added (e.g. (e.g., URIs or "alpn"), resolvers
SHOULD
<bcp14>SHOULD</bcp14> limit validation to specified constraints.</t>
        <t>When responding to a query that includes the DNSSEC OK bit (<xref target="RFC3225"/>), <xref target="RFC3225"/>,
DNSSEC-capable recursive and authoritative DNS servers MUST <bcp14>MUST</bcp14> accompany
each RRSet RRset in the Additional section with the same DNSSEC-related records
that they would send when providing that RRSet RRset as an Answer (e.g. (e.g., RRSIG, NSEC,
NSEC3).</t>
        <t>According to <xref section="5.4.1" sectionFormat="of" target="RFC2181"/>, "Unauthenticated RRs received
and cached from ... the additional data section ... should not be cached in
such a way that they would ever be returned as answers to a received query.
They may be returned as additional information where appropriate.". appropriate."
Recursive resolvers therefore MAY <bcp14>MAY</bcp14> cache records from the Additional section
for use in populating Additional section responses, responses and MAY <bcp14>MAY</bcp14> cache them
for general use if they are authenticated by DNSSEC.</t>
      </section>
      <section anchor="ecs">
        <name>EDNS Client Subnet (ECS)</name>
        <t>The EDNS Client Subnet (ECS) option (ECS, <xref target="RFC7871"/>) target="RFC7871"/> allows recursive
resolvers to request IP addresses that are suitable for a particular client
IP range.  SVCB records may contain IP addresses (in ipv*hint SvcParams), SvcParams)
or direct users to a subnet-specific TargetName, so recursive resolvers
SHOULD
<bcp14>SHOULD</bcp14> include the same ECS option in SVCB queries as in A/AAAA queries.</t>
        <t>According to <xref section="7.3.1" sectionFormat="of" target="RFC7871"/>, "Any records from [the
Additional section] MUST NOT <bcp14>MUST NOT</bcp14> be tied to a network". network."  Accordingly,
when processing a response whose QTYPE is SVCB-compatible,
resolvers SHOULD <bcp14>SHOULD</bcp14> treat any records in the Additional section as having
SOURCE PREFIX-LENGTH set to zero and SCOPE PREFIX-LENGTH as specified
in the ECS option.  Authoritative servers MUST <bcp14>MUST</bcp14> omit such records if they are
not suitable for use by any stub resolvers that set SOURCE PREFIX-LENGTH to
zero.  This will cause the resolver to perform a follow-up query that can
receive a properly tailored ECS.  (This is similar to the usage of CNAME with
the ECS option as discussed in <xref section="7.2.1" sectionFormat="comma" target="RFC7871"/>.)</t>
        <t>Authoritative servers that omit Additional records can avoid the added
latency of a follow-up query by following the advice in <xref target="zone-performance"/>.</t>
      </section>
    </section>
    <section anchor="optimizations">
      <name>Performance optimizations</name> Optimizations</name>
      <t>For optimal performance (i.e. (i.e., minimum connection setup time), clients
SHOULD
<bcp14>SHOULD</bcp14> implement a client-side DNS cache.
Responses in the Additional section of a SVCB response SHOULD <bcp14>SHOULD</bcp14> be placed
in cache before performing any follow-up queries.
With this behavior, and with conforming DNS servers,
using SVCB does not add network latency to connection setup.</t>
      <t>To improve performance when using a non-conforming recursive resolver, clients
SHOULD
<bcp14>SHOULD</bcp14> issue speculative A and/or AAAA queries in parallel with each SVCB
query, based on a predicted value of TargetName (see <xref target="zone-performance"/>).</t>
      <t>After a ServiceMode RRSet RRset is received, clients MAY <bcp14>MAY</bcp14> try more than one option
in parallel, parallel and MAY <bcp14>MAY</bcp14> prefetch A and AAAA records for multiple TargetNames.</t>
      <section anchor="optimistic-pre-connection-and-connection-reuse">
        <name>Optimistic pre-connection Pre-connection and connection reuse</name> Connection Reuse</name>
        <t>If an address response arrives before the corresponding SVCB response, the
client MAY <bcp14>MAY</bcp14> initiate a connection as if the SVCB query returned NODATA, NODATA but
MUST NOT
<bcp14>MUST NOT</bcp14> transmit any information that could be altered by the SVCB response
until it arrives.  For example, future SvcParamKeys could be defined that
alter the TLS ClientHello.</t>
        <t>Clients
implementing this optimization SHOULD <bcp14>SHOULD</bcp14> wait for 50 milliseconds before
starting optimistic pre-connection, as per the guidance in
<xref target="HappyEyeballsV2"/>.</t> target="RFC8305"/>.</t>
        <t>A SVCB record is consistent with a connection
if the client would attempt an equivalent connection when making use of
that record. If a SVCB record is consistent with an active or in-progress
connection C, the client MAY <bcp14>MAY</bcp14> prefer that record and use C as its connection.
For example, suppose the client receives this SVCB RRSet RRset for a protocol
that uses TLS over TCP:</t>
        <artwork><![CDATA[
        <sourcecode type="dns-rr"><![CDATA[
_1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. (
    ipv6hint=2001:db8::1 port=1234 )
                               SVCB 2 svc2.example.net. (
    ipv6hint=2001:db8::2 port=1234 )
]]></artwork>
]]></sourcecode>
        <t>If the client has an in-progress TCP connection to <tt>[2001:db8::2]:1234</tt>,
it MAY <bcp14>MAY</bcp14> proceed with TLS on that connection, even
though the other record in the RRSet RRset has higher priority.</t>
        <t>If none of the SVCB records are consistent
with any active or in-progress connection,
clients proceed with connection establishment as described in
<xref target="client-behavior"/>.</t>
      </section>
      <section anchor="incomplete-response">
        <name>Generating and using incomplete responses</name> Using Incomplete Responses</name>
        <t>When following the procedure in <xref target="recursive-behavior"/>, recursive
resolvers MAY <bcp14>MAY</bcp14> terminate the procedure early and produce a reply that omits
some of the associated RRSets. RRsets.  This is REQUIRED <bcp14>REQUIRED</bcp14> when the chain length limit
is reached (<xref target="recursive-behavior"/> step 1), (Step 1 in <xref target="recursive-behavior"/>) but might also be appropriate
when the maximum response size is reached, reached or when responding before fully
chasing dependencies would improve performance.  When omitting certain
RRSets,
RRsets, recursive resolvers SHOULD <bcp14>SHOULD</bcp14> prioritize information for
smaller-SvcPriority records.</t>
        <t>As discussed in <xref target="client-behavior"/>, clients MUST <bcp14>MUST</bcp14> be able to fetch additional
information that is required to use a SVCB record, if it is not included
in the initial response.  As a performance optimization, if some of the SVCB
records in the response can be used without requiring additional DNS queries,
the client MAY <bcp14>MAY</bcp14> prefer those records, regardless of their priorities.</t>
      </section>
    </section>
    <section anchor="svcb-compatible">
      <name>SVCB-compatible</name>
      <name>SVCB-Compatible RR Types</name>
      <t>An RR type is called "SVCB-compatible" if it permits an implementation that is
identical to SVCB in its:</t>
      <ul spacing="normal">
        <li>RDATA presentation format</li>
        <li>RDATA wire format</li>
        <li>IANA registry used for SvcParamKeys</li>
        <li>Authoritative server Additional Section section processing</li>
        <li>Recursive resolution process</li>
        <li>Relevant Class (i.e. (i.e., Internet ("IN") <xref target="RFC1035"/>)</li>
      </ul>
      <t>This allows authoritative and recursive DNS servers to apply identical
processing to all SVCB-compatible RR types.</t>
      <t>All other behaviors described as applying to the SVCB RR also apply
to all SVCB-compatible RR types unless explicitly stated otherwise.
When following an AliasMode record (<xref target="alias-mode"/>) of RR type $T , $T, the
followup
follow-up query to the TargetName MUST <bcp14>MUST</bcp14> also be for type $T.</t>
      <t>This document defines one SVCB-compatible RR type (other than SVCB itself):
the HTTPS RR type (<xref target="https"/>), which avoids Attrleaf label prefixes <xref target="Attrleaf"/> target="RFC8552"/> in order to improve
compatibility with wildcards and CNAMEs, which are widely used with HTTP.</t>
      <t>Standards authors should consider carefully whether to use SVCB or define a
new SVCB-compatible RR type, as this choice cannot easily be reversed after
deployment.</t>
    </section>
    <section anchor="keys">
      <name>Initial SvcParamKeys</name>
      <t>A few initial SvcParamKeys are defined here.  These keys are useful for the
"https" scheme, and most are expected to be generally applicable to other
schemes as well.</t>
      <t>Each new protocol
mapping document MUST <bcp14>MUST</bcp14> specify which keys are applicable and safe to use.
Protocol mappings MAY <bcp14>MAY</bcp14> alter the interpretation of SvcParamKeys but MUST NOT <bcp14>MUST NOT</bcp14>
alter their presentation or wire formats.</t>
      <section anchor="alpn-key">
        <name>"alpn" and "no-default-alpn"</name>
        <t>The "alpn" and "no-default-alpn" SvcParamKeys together
indicate the set of Application Layer Application-Layer Protocol Negotiation (ALPN)
protocol identifiers <xref target="ALPN"/> target="RFC7301"/>
and associated transport protocols supported by this service endpoint (the
"SVCB ALPN set").</t>
        <t>As with Alt-Svc <xref target="AltSvc"/>, target="RFC7838"/>, each ALPN protocol identifier is used to
identify the application protocol and associated suite
of protocols supported by the endpoint (the "protocol suite").
The presence of an ALPN protocol identifier in the SVCB ALPN set indicates that this
service endpoint, described by TargetName and the other parameters (e.g.
"port") (e.g.,
"port"), offers service with the protocol suite associated with this ALPN identifier.</t>
        <t>Clients filter the set of ALPN identifiers to match the protocol suites they
support, and this informs the underlying transport protocol used (such
as QUIC-over-UDP QUIC over UDP or TLS-over-TCP). TLS over TCP).  ALPN protocol identifiers that do not uniquely
identify a protocol suite (e.g. (e.g., an Identification Sequence that
can be used with both TLS and DTLS) are not compatible with this
SvcParamKey and MUST NOT <bcp14>MUST NOT</bcp14> be included in the SVCB ALPN set.</t>
        <section anchor="representation">
          <name>Representation</name>
          <t>ALPNs are identified by their registered "Identification Sequence"
(<tt>alpn-id</tt>), which is a sequence of 1-255 octets.</t>
          <artwork><![CDATA[
<sourcecode name="" type="abnf"><![CDATA[
alpn-id = 1*255OCTET
]]></artwork>
]]></sourcecode>
          <t>For "alpn", the presentation <tt>value</tt> SHALL <bcp14>SHALL</bcp14> be
a comma-separated list (<xref target="value-list"/>)
of one or more <tt>alpn-id</tt>s.  Zone file  Zone-file implementations MAY <bcp14>MAY</bcp14> disallow the
"," and "\" characters in ALPN IDs instead of implementing the <tt>value-list</tt> escaping
procedure, relying on the opaque key format (e.g. (e.g., <tt>key1=\002h2</tt>) in the
event that these characters are needed.</t>
          <t>The wire format wire-format value for "alpn" consists of at least one
<tt>alpn-id</tt> prefixed by its length as a single octet, and these length-value
pairs are concatenated to form the SvcParamValue.  These pairs MUST <bcp14>MUST</bcp14> exactly
fill the SvcParamValue; otherwise, the SvcParamValue is malformed.</t>
          <t>For "no-default-alpn", the presentation and wire format wire-format values MUST <bcp14>MUST</bcp14> be
empty.  When "no-default-alpn" is specified in an RR,
"alpn" must also be specified in order for the RR
to be "self-consistent" (<xref target="service-mode"/>).</t>
          <t>Each scheme that uses this SvcParamKey defines a "default set" of ALPNs ALPN IDs
that are supported by nearly all clients and servers, which MAY servers; this set <bcp14>MAY</bcp14>
be empty.  To determine the SVCB ALPN set, the client starts with the list of
<tt>alpn-id</tt>s from the "alpn" SvcParamKey, and it adds the default set unless the
"no-default-alpn" SvcParamKey is present.</t>
        </section>
        <section anchor="use">
          <name>Use</name>
          <t>To establish a connection to the endpoint, clients MUST</t> <bcp14>MUST</bcp14></t>
          <ol spacing="normal" type="1"><li>Let SVCB-ALPN-Intersection be the set of protocols in the SVCB ALPN set
that the client supports.</li>
            <li>Let Intersection-Transports be the set of transports (e.g. (e.g., TLS, DTLS, QUIC)
implied by the protocols in SVCB-ALPN-Intersection.</li>
            <li>For each transport in Intersection-Transports, construct a ProtocolNameList
containing the Identification Sequences of all the client's supported ALPN
protocols for that transport, without regard to the SVCB ALPN set.</li>
          </ol>
          <t>For example, if the SVCB ALPN set is ["http/1.1", "h3"], "h3"] and the client
supports HTTP/1.1, HTTP/2, and HTTP/3, the client could attempt to connect using
TLS over TCP with a ProtocolNameList of ["http/1.1", "h2"], "h2"] and could also
attempt a connection using QUIC, QUIC with a ProtocolNameList of ["h3"].</t>
          <t>Once the client has constructed a ClientHello, protocol negotiation in that
handshake proceeds as specified in <xref target="ALPN"/>, target="RFC7301"/>, without regard to the SVCB ALPN
set.</t>
          <t>Clients MAY <bcp14>MAY</bcp14> implement a fallback procedure, using a less-preferred transport
if more-preferred transports fail to connect.  This fallback behavior is
vulnerable to manipulation by a network attacker who blocks the more-preferred
transports, but it may be necessary for compatibility with existing networks.</t>
          <t>With this procedure in place, an attacker who can modify DNS and network
traffic can prevent a successful transport connection, connection but cannot otherwise
interfere with ALPN protocol selection.  This procedure also ensures that
each ProtocolNameList includes at least one protocol from the SVCB ALPN set.</t>
          <t>Clients SHOULD NOT <bcp14>SHOULD NOT</bcp14> attempt connection to a service endpoint whose SVCB
ALPN set does not contain any supported protocols.</t>
          <t>To ensure
consistency of behavior, clients MAY <bcp14>MAY</bcp14> reject the entire SVCB RRSet RRset and fall
back to basic connection establishment if all of the compatible RRs indicate
"no-default-alpn", even if connection could have succeeded using a
non-default alpn.</t> ALPN protocol.</t>
          <t>Zone operators SHOULD <bcp14>SHOULD</bcp14> ensure that at least one RR in each RRSet RRset supports the
default transports.  This enables compatibility with the greatest number of
clients.</t>
        </section>
      </section>
      <section anchor="svcparamkeys-port">
        <name>"port"</name>
        <t>The "port" SvcParamKey defines the TCP or UDP port
that should be used to reach this alternative endpoint.
If this key is not present, clients SHALL <bcp14>SHALL</bcp14> use the authority endpoint's port
number.</t>
        <t>The presentation <tt>value</tt> of the SvcParamValue is a single decimal integer
between 0 and 65535 in ASCII.  Any other <tt>value</tt> (e.g. (e.g., an empty value)
is a syntax error.  To enable simpler parsing, this SvcParam MUST NOT SvcParamValue <bcp14>MUST NOT</bcp14> contain
escape sequences.</t>
        <t>The wire format of the SvcParamValue
is the corresponding 2 octet 2-octet numeric value in network byte order.</t>
        <t>If a port-restricting firewall is in place between some client and the service
endpoint, changing the port number might cause that client to lose access to
the service, so operators should exercise caution when using this SvcParamKey
to specify a non-default port.</t>
      </section>
      <section anchor="svcparamkeys-iphints">
        <name>"ipv4hint" and "ipv6hint"</name>
        <t>The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY <bcp14>MAY</bcp14> use to
reach the service.  If A and AAAA records for TargetName are locally
available, the client SHOULD <bcp14>SHOULD</bcp14> ignore these hints.  Otherwise, clients
SHOULD
<bcp14>SHOULD</bcp14> perform A and/or AAAA queries for TargetName as in per
<xref target="client-behavior"/>, and clients SHOULD <bcp14>SHOULD</bcp14> use the IP address in those
responses for future connections. Clients MAY <bcp14>MAY</bcp14> opt to terminate any
connections using the addresses in hints and instead switch to the
addresses in response to the TargetName query. Failure to use A and/or
AAAA response addresses could negatively impact load balancing or other
geo-aware features and thereby degrade client performance.</t>
        <t>The presentation <tt>value</tt> SHALL <bcp14>SHALL</bcp14> be a comma-separated list (<xref target="value-list"/>)
of one or more IP addresses of the appropriate
family in standard textual format <xref target="RFC5952"/><xref target="RFC5952"/> <xref target="RFC4001"/>.  To enable simpler parsing,
this SvcParamValue MUST NOT <bcp14>MUST NOT</bcp14> contain escape sequences.</t>
        <t>The wire format for each parameter is a sequence of IP addresses in network
byte order (for the respective address-family). address family).
Like an A or AAAA RRSet, RRset, the list of addresses represents an
unordered collection, and clients SHOULD <bcp14>SHOULD</bcp14> pick addresses to use in a random order.
An empty list of addresses is invalid.</t>
        <t>When selecting between IPv4 and IPv6 addresses to use, clients may use an
approach such as Happy Eyeballs <xref target="HappyEyeballsV2"/>. target="RFC8305"/>.
When only "ipv4hint" is present, NAT64 clients may synthesize
IPv6 addresses as specified in <xref target="RFC7050"/> or ignore the "ipv4hint" key and
wait for AAAA resolution (<xref target="client-behavior"/>).
For best performance, server operators SHOULD <bcp14>SHOULD</bcp14> include an "ipv6hint" parameter
whenever they include an "ipv4hint" parameter.</t>
        <t>These parameters are intended to minimize additional connection latency
when a recursive resolver is not compliant with the requirements in
<xref target="server-behavior"/>, target="server-behavior"/> and SHOULD NOT <bcp14>SHOULD NOT</bcp14> be included if most clients are using
compliant recursive resolvers.  When TargetName is the origin hostname service name
or the owner name (which can be written as "."), server operators
SHOULD NOT
<bcp14>SHOULD NOT</bcp14> include these hints, because they are unlikely to convey any
performance benefit.</t>
      </section>
      <section anchor="svcparamkey-mandatory">
        <name>"mandatory"</name>
        <t>See <xref target="mandatory"/>.</t>
      </section>
    </section>
    <section anchor="mandatory">
      <name>ServiceMode RR compatibility Compatibility and mandatory keys</name> Mandatory Keys</name>
      <t>In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will not
function correctly for clients that ignore this SvcParamKey.  Each SVCB
protocol mapping SHOULD <bcp14>SHOULD</bcp14> specify a set of keys that are "automatically
mandatory", i.e. i.e., mandatory if they are present in an RR.  The SvcParamKey
"mandatory" is used to indicate any mandatory keys for this RR, in addition to
any automatically mandatory keys that are present.</t>
      <t>A ServiceMode RR is considered "compatible" by a client if the client
recognizes all the mandatory keys, keys and their values indicate that successful
connection establishment is possible.  If the SVCB RRSet contains
no compatible RRs, the client will generally act as if  Incompatible RRs are ignored (see step 5 of the RRSet is empty.</t> procedure defined in <xref target="client-behavior"/>).</t>
      <t>The presentation <tt>value</tt> SHALL <bcp14>SHALL</bcp14> be a comma-separated list
(<xref target="value-list"/>) of one or more valid
SvcParamKeys, either by their registered name or in the unknown-key format
(<xref target="presentation"/>).  Keys MAY <bcp14>MAY</bcp14> appear in any order, order but MUST NOT <bcp14>MUST NOT</bcp14> appear more
than once.  For self-consistency (<xref target="service-mode"/>), listed keys MUST <bcp14>MUST</bcp14> also
appear in the SvcParams.</t>
      <t>To enable simpler parsing, this
SvcParamValue MUST NOT <bcp14>MUST NOT</bcp14> contain escape sequences.</t>
      <t>For example, the following is a valid list of SvcParams:</t>
      <artwork><![CDATA[
      <sourcecode><![CDATA[
ipv6hint=... key65333=ex1 key65444=ex2 mandatory=key65444,ipv6hint
]]></artwork>
]]></sourcecode>
      <t>In wire format, the keys are represented by their numeric values in
network byte order, concatenated in strictly increasing numeric order.</t>
      <t>This SvcParamKey is always automatically mandatory, mandatory and MUST NOT <bcp14>MUST NOT</bcp14> appear in its
own value-list.  Other automatically mandatory keys SHOULD NOT <bcp14>SHOULD NOT</bcp14> appear in the
list either.  (Including them wastes space and otherwise has no effect.)</t>
    </section>
    <section anchor="https">
      <name>Using Service Bindings with HTTP</name>
      <t>Use
      <t>The use of any protocol with SVCB requires a protocol-specific mapping
specification.  This section specifies the mapping for the "http" and "https"
URI schemes <xref target="HTTP"/>.</t> target="RFC9110"/>.</t>
      <t>To enable special handling for HTTP use-cases, use cases,
the HTTPS RR type is defined as a SVCB-compatible RR type,
specific to the "https" and "http" schemes.  Clients MUST NOT <bcp14>MUST NOT</bcp14>
perform SVCB queries or accept SVCB responses for "https"
or "http" schemes.</t>
      <t>The presentation format of the record is:</t>
      <artwork><![CDATA[
      <sourcecode><![CDATA[
Name TTL IN HTTPS SvcPriority TargetName SvcParams
]]></artwork>
]]></sourcecode>
      <t>All the SvcParamKeys defined in <xref target="keys"/> are permitted for use in
HTTPS RRs.  The default set of ALPN IDs is the single value "http/1.1".
The "automatically mandatory" keys (<xref target="mandatory"/>) are "port"
and "no-default-alpn".  (As described in <xref target="mandatory"/>, clients must
either implement these keys or ignore any RR in which they appear.)
Clients that restrict the destination port in "https" URIs
(e.g.
(e.g., using the "bad ports" list from <xref target="FETCH"/>) SHOULD <bcp14>SHOULD</bcp14> apply the
same restriction to the "port" SvcParam.</t>
      <t>The presence of an HTTPS RR for an origin also indicates
that clients should connect securely and use the "https" scheme, as
discussed in <xref target="hsts"/>.  This allows HTTPS RRs to apply to
pre-existing "http" scheme URLs, while ensuring that the client uses a
secure and authenticated connection.</t>
      <t>The HTTPS RR parallels the concepts
introduced in the HTTP "HTTP Alternative Services proposed standard Services" <xref target="AltSvc"/>. target="RFC7838"/>.  Clients and servers that implement HTTPS RRs are
not required to implement Alt-Svc.</t>
      <section anchor="httpsnames">
        <name>Query names Names for HTTPS RRs</name>
        <t>The HTTPS RR uses Port Prefix Naming (<xref target="svcb-names"/>),
with one modification: if the scheme is "https" and the port is 443,
then the client's original QNAME is
equal to the service name (i.e. (i.e., the origin's hostname),
without any prefix labels.</t>
        <t>By removing the Attrleaf labels <xref target="Attrleaf"/> target="RFC8552"/>
used in SVCB, this construction enables offline DNSSEC signing of
wildcard domains, which are commonly used with HTTP.  Using the
service name as the owner name of the HTTPS record, without prefixes,
also allows the targets of existing CNAME chains
(e.g.
(e.g., CDN hosts) to start returning HTTPS RR responses without
requiring origin domains to configure and maintain an additional
delegation.</t>
        <t>Following of
        <t>The procedure for following HTTPS AliasMode RRs and CNAME aliases is unchanged from SVCB.</t> SVCB (as described in Sections&nbsp;<xref target="alias-mode" format="counter"/> and <xref target="client-behavior" format="counter"/>).</t>
        <t>Clients always convert "http" URLs to "https" before performing an
HTTPS RR query using the process described in <xref target="hsts"/>, so domain owners
MUST NOT
<bcp14>MUST NOT</bcp14> publish HTTPS RRs with a prefix of "_http".</t>
        <t>Note that none of these forms alter the HTTPS origin or authority.
For example, clients MUST <bcp14>MUST</bcp14> continue to validate TLS certificate
hostnames based on the origin.</t>
      </section>
      <section anchor="comparison-with-alt-svc">
        <name>Comparison with Alt-Svc</name>
        <t>Publishing a ServiceMode HTTPS RR in DNS is intended
to be similar to transmitting an Alt-Svc field value over
HTTP, and receiving an HTTPS RR is intended to be similar to
receiving that field value over HTTP.  However, there are some
differences in the intended client and server behavior.</t>
        <section anchor="alpn-usage">
          <name>ALPN usage</name> Usage</name>
          <t>Unlike Alt-Svc Field Values, field values, HTTPS RRs can contain multiple ALPN IDs.  The
meaning and use of these IDs is are discussed in <xref target="use"/>.</t>
        </section>
        <section anchor="untrusted-channel">
          <name>Untrusted channel</name> Channels</name>
          <t>HTTPS records do not require or provide any assurance of authenticity.  (DNSSEC
signing and verification, which would provide such assurance, are OPTIONAL.) <bcp14>OPTIONAL</bcp14>.)
The DNS resolution process is modeled as an untrusted channel that might be
controlled by an attacker, so
Alt-Svc parameters that cannot be safely received in this model MUST NOT <bcp14>MUST NOT</bcp14>
have a corresponding defined SvcParamKey.  For example, there is no
SvcParamKey corresponding to the Alt-Svc "persist" parameter, because
this parameter is not safe to accept over an untrusted channel.</t>
        </section>
        <section anchor="cache-lifetime">
          <name>Cache lifetime</name> Lifetime</name>
          <t>There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) parameter.
Instead, server operators encode the expiration time in the DNS TTL.</t>
          <t>The appropriate TTL value might be different from the "ma" value
used for Alt-Svc, depending on the desired efficiency and
agility.  Some DNS caches incorrectly extend the lifetime of DNS
records beyond the stated TTL, so server operators cannot rely on
HTTPS RRs expiring on time.  Shortening the TTL to compensate
for incorrect caching is NOT RECOMMENDED, <bcp14>NOT RECOMMENDED</bcp14>, as this practice impairs the
performance of correctly functioning caches and does not guarantee
faster expiration from incorrect caches.  Instead, server operators
SHOULD
<bcp14>SHOULD</bcp14> maintain compatibility with expired records until they observe
that nearly all connections have migrated to the new configuration.</t>
        </section>
        <section anchor="granularity">
          <name>Granularity</name>
          <t>Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc
Field Value
field value specifically to the client.  When using an HTTPS RR,
groups of clients will necessarily receive the same SvcParams.
Therefore, HTTPS RRs are not suitable for uses that require
single-client granularity.</t>
        </section>
      </section>
      <section anchor="interaction-with-alt-svc">
        <name>Interaction with Alt-Svc</name>
        <t>Clients that implement support for both Alt-Svc and HTTPS records and
are making a connection based on a cached Alt-Svc response SHOULD <bcp14>SHOULD</bcp14>
retrieve any HTTPS records for the Alt-Svc alt-authority, alt-authority and ensure that
their connection attempts are consistent with both the Alt-Svc parameters
and any received HTTPS SvcParams.  If present, the HTTPS record's TargetName
and port are used for connection establishment (as in (per <xref target="client-behavior"/>).
For example, suppose that
"https://example.com" sends an Alt-Svc field value of:</t>
        <sourcecode type="HTTP"><![CDATA[ type="http-message"><![CDATA[
Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443"
]]></sourcecode>
        <t>The client would retrieve the following HTTPS records:</t>
        <artwork><![CDATA[
        <sourcecode type="dns-rr"><![CDATA[
alt.example.              IN HTTPS 1 . alpn=h2,h3 foo=...
alt2.example.             IN HTTPS 1 alt2b.example. alpn=h3 foo=...
_8443._https.example.com. IN HTTPS 1 alt3.example. (
    port=9443 alpn=h2,h3 foo=... )
]]></artwork>
]]></sourcecode>
        <t>Based on these inputs, the following connection attempts would always be
allowed:</t>
        <ul spacing="normal">
          <li>HTTP/2 to <tt>alt.example:443</tt></li>
          <li>HTTP/3 to <tt>alt3.example:9443</tt></li>
          <li>Fallback to the client's non-Alt-Svc connection behavior</li>
        </ul>
        <t>The following connection attempts would not be allowed:</t>
        <ul spacing="normal">
          <li>HTTP/3 to <tt>alt.example:443</tt> (not consistent with Alt-Svc)</li>
          <li>Any connection to <tt>alt2b.example</tt> (no ALPN ID consistent with both the HTTPS
record and Alt-Svc)</li>
          <li>HTTPS over TCP to any port on <tt>alt3.example</tt> (not consistent with Alt-Svc)</li>
        </ul>
        <t>Suppose that "foo" is a SvcParamKey that renders the client SVCB-reliant.
The following Alt-Svc-only connection attempts would be allowed only if
the client does not support "foo", as they rely on SVCB-optional fallback
behavior:</t>
        <ul spacing="normal">
          <li>HTTP/2 to <tt>alt2.example:443</tt></li>
          <li>HTTP/3 to <tt>example.com:8443</tt></li>
        </ul>
        <t>Alt-authorities SHOULD <bcp14>SHOULD</bcp14> carry the same SvcParams as the origin unless
a deviation is specifically known to be safe.
As noted in <xref section="2.4" sectionFormat="of" target="AltSvc"/>, target="RFC7838"/>, clients MAY <bcp14>MAY</bcp14> disallow any Alt-Svc
connection according to their own criteria, e.g. e.g., disallowing Alt-Svc
connections that lack support for privacy features that are available on
the origin authority endpoint.</t>
      </section>
      <section anchor="requiring-server-name-indication">
        <name>Requiring Server Name Indication</name>
        <t>Clients MUST NOT <bcp14>MUST NOT</bcp14> use an HTTPS RR response unless the
client supports the TLS Server Name Indication (SNI) extension and
indicates the origin name in the TLS ClientHello (which might be
encrypted via a future specification such as ECH). <xref target="I-D.ietf-tls-esni"/>).
This supports the conservation of IP addresses.</t>
        <t>Note that the TLS SNI (and also the HTTP "Host" or ":authority") will indicate
the origin, not the TargetName.</t>
      </section>
      <section anchor="hsts">
        <name>HTTP Strict Transport Security</name> Security (HSTS)</name>
        <t>An HTTPS RR directs the client to communicate with this host only over a
secure transport, similar to HTTP Strict Transport Security HSTS <xref target="HSTS"/>. target="RFC6797"/>.
Prior to making an "http" scheme request, the client SHOULD <bcp14>SHOULD</bcp14> perform a lookup
to determine if any HTTPS RRs exist for that origin.  To do so,
the client SHOULD <bcp14>SHOULD</bcp14> construct a corresponding "https" URL as follows:</t>
        <ol spacing="normal" type="1"><li>Replace the "http" scheme with "https".</li>
          <li>If the "http" URL explicitly specifies port 80, specify port 443.</li>
          <li>Do not alter any other aspect of the URL.</li>
        </ol>
        <t>This construction is equivalent to <xref section="8.3" sectionFormat="of" target="HSTS"/>, point target="RFC6797"/>, Step 5.</t>
        <t>If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS RRs, RRs
or any compatible ServiceMode HTTPS RRs (see <xref target="mandatory"/>), the client
SHOULD
<bcp14>SHOULD</bcp14> behave as if it has received an HTTP 307 (Temporary Redirect) status code
with this "https" URL in the "Location" field.  (Receipt of an incompatible ServiceMode RR does not
trigger the redirect behavior.)
Because HTTPS RRs are received over an often-insecure channel (DNS),
clients MUST NOT <bcp14>MUST NOT</bcp14> place any more trust in this signal than if they
had received a 307 (Temporary Redirect) response over cleartext HTTP.</t>
        <t>Publishing an HTTPS RR has the potential can potentially lead to have unexpected results
or a loss in functionality in cases where the "http" resource neither
redirects to the "https" resource nor references the same underlying resource.</t>
        <t>When an "https" connection fails due to an error in the underlying secure
transport, such as an error in certificate validation, some clients
currently offer a "user recourse" that allows the user to bypass the
security error and connect anyway.
When making an "https" scheme request to an origin with an HTTPS RR,
either directly or via the above redirect, such a client MAY <bcp14>MAY</bcp14> remove the user
recourse option.  Origins that publish HTTPS RRs therefore MUST NOT <bcp14>MUST NOT</bcp14> rely
on user recourse for access.  For more information, see Section Sections <xref target="HSTS" target="RFC6797" section="8.4" sectionFormat="bare"/> and Section <xref target="HSTS" target="RFC6797" section="12.1" sectionFormat="bare"/> of <xref target="HSTS"/>.</t> target="RFC6797"/>.</t>
      </section>
      <section anchor="use-of-https-rrs-in-other-protocols">
        <name>Use of HTTPS RRs in other protocols</name> Other Protocols</name>
        <t>All HTTP connections to named origins are eligible to use HTTPS RRs, even
when HTTP is used as part of another protocol or without an explicit HTTP
URL. HTTP-related URI
scheme (<relref target="RFC9110" section="4.2"/>).  For example, clients that
support HTTPS RRs and implement <xref target="RFC6455"/> using the altered WebSocket <xref target="WebSocket"/>
opening handshake from the W3C Fetch specification <xref target="FETCH"/> SHOULD target="FETCH-WEBSOCKETS"/> <bcp14>SHOULD</bcp14> use HTTPS RRs
for the <tt>requestURL</tt>.</t>
        <t>When HTTP is used in a context where URLs or redirects are not applicable
(e.g.
(e.g., connections to an HTTP proxy), clients that find a corresponding HTTPS RR
SHOULD
<bcp14>SHOULD</bcp14> implement a security upgrade behavior equivalent to the one that
specified in
<xref target="hsts"/>.</t>
        <t>Such protocols MAY <bcp14>MAY</bcp14> define their own SVCB mappings, which MAY <bcp14>MAY</bcp14>
be defined to take precedence over HTTPS RRs.</t>
      </section>
    </section>
    <section anchor="zone-structures">
      <name>Zone Structures</name>
      <section anchor="structuring-zones-for-flexibility">
        <name>Structuring zones Zones for flexibility</name> Flexibility</name>
        <t>Each ServiceMode RRSet RRset can only serve a single scheme.  The scheme is indicated
by the owner name and the RR type.  For the generic SVCB RR type, this means that
each owner name can only be used for a single scheme.  The underscore prefixing
requirement (<xref target="svcb-names"/>) ensures that this is true for the initial query,
but it is the responsibility of zone owners to choose names that satisfy this
constraint when using aliases, including CNAME and AliasMode records.</t>
        <t>When using the generic SVCB RR type with aliasing, zone owners SHOULD <bcp14>SHOULD</bcp14> choose alias
target names that indicate the scheme in use (e.g. <tt>foosvc.example.net</tt> (e.g., "foosvc.example.net" for
<tt>foo://</tt>
"foo" schemes).  This will help to avoid confusion when another scheme needs to
be added to the configuration.  When multiple port numbers are in use, it may be
helpful to repeat the prefix labels in the alias target name (e.g.
<tt>_1234._foo.svc.example.net</tt>).</t> (e.g.,
"_1234._foo.svc.example.net").</t>
      </section>
      <section anchor="zone-performance">
        <name>Structuring zones Zones for performance</name> Performance</name>
        <t>To avoid a delay for clients using a nonconforming non-conforming recursive resolver,
domain owners SHOULD <bcp14>SHOULD</bcp14> minimize the use of AliasMode records, records and SHOULD <bcp14>SHOULD</bcp14>
choose TargetName according to a predictable convention that is known
to the client, so that clients can issue A and/or AAAA queries for TargetName
in advance (see <xref target="optimizations"/>).  Unless otherwise specified, the
convention is to set TargetName to the service name for an initial
ServiceMode record, or to "." if it is reached via an alias.</t>
        <figure>
          <name>foo://foo.example.com:8080 is delegated to foosvc.example.net,
          <name>"foo://foo.example.com:8080" Is Available at "foosvc.example.net", but bar://bar.example.com:9090 is served locally.</name>
          <artwork><![CDATA[ "bar://bar.example.com:9090" Is Served Locally</name>
          <sourcecode type="dns-rr"><![CDATA[
$ORIGIN example.com. ; Origin
foo                  3600 IN CNAME foosvc.example.net.
_8080._foo.foo       3600 IN CNAME foosvc.example.net.
bar                   300 IN AAAA 2001:db8::2
_9090._bar.bar       3600 IN SVCB 1 bar key65444=...

$ORIGIN example.net. ; Service provider zone
foosvc               3600 IN SVCB 1 . key65333=...
foosvc                300 IN AAAA 2001:db8::1
]]></artwork>
]]></sourcecode>
        </figure>
        <t>Domain owners SHOULD <bcp14>SHOULD</bcp14> avoid using a TargetName that is below a DNAME, as
this is likely unnecessary and makes responses slower and larger.
Also, zone structures that require following more than 8 eight aliases
(counting both AliasMode and CNAME records) are NOT RECOMMENDED.</t> <bcp14>NOT RECOMMENDED</bcp14>.</t>
      </section>
      <section anchor="operational-considerations">
        <name>Operational considerations</name>
        <t>Note that some implementations Considerations</name>
        <t>Some authoritative DNS servers may not allow A or AAAA records on names
starting with an underscore due to various interpretations of RFCs. (e.g., <xref target="BIND-CHECK-NAMES"/>).
This could be create an operational issue when the TargetName contains an attrleaf Attrleaf label,
as well as
or when using an a TargetName of "." when if the owner name contains an attrleaf Attrleaf label.</t>
      </section>
      <section anchor="examples">
        <name>Examples</name>
        <section anchor="protocol-enhancements">
          <name>Protocol enhancements</name> Enhancements</name>
          <t>Consider a simple zone of the form:</t>
          <artwork><![CDATA[
          <sourcecode type="dns-rr"><![CDATA[
$ORIGIN simple.example. ; Simple example zone
@ 300 IN A    192.0.2.1
         AAAA 2001:db8::1
]]></artwork>
]]></sourcecode>
          <t>The domain owner could add this record:</t>
          <artwork><![CDATA[
          <sourcecode type="dns-rr"><![CDATA[
@ 7200 IN HTTPS 1 . alpn=h3
]]></artwork>
          <t>to
]]></sourcecode>
          <t>This record would indicate that https://simple.example "https://simple.example" supports QUIC
in addition to HTTP/1.1 over TLS over TCP (the implicit default).
The record could also include other information (e.g. (e.g., a non-standard port).
For https://simple.example:8443, "https://simple.example:8443", the record would be:</t>
          <artwork><![CDATA[
          <sourcecode type="dns-rr"><![CDATA[
_8443._https 7200 IN HTTPS 1 . alpn=h3
]]></artwork>
]]></sourcecode>
          <t>These records also respectively tell clients to replace the scheme with "https" when
loading http://simple.example "http://simple.example" or http://simple.example:8443.</t> "http://simple.example:8443".</t>
        </section>
        <section anchor="apex-aliasing">
          <name>Apex aliasing</name> Aliasing</name>
          <t>Consider a zone that is using CNAME aliasing:</t>
          <artwork><![CDATA[
          <sourcecode type="dns-rr"><![CDATA[
$ORIGIN aliased.example. ; A zone that is using a hosting service
; Subdomain aliased to a high-performance server pool
www             7200 IN CNAME pool.svc.example.
; Apex domain on fixed IPs because CNAME is not allowed at the apex
@                300 IN A     192.0.2.1
                     IN AAAA  2001:db8::1
]]></artwork>
]]></sourcecode>
          <t>With HTTPS RRs, the owner of aliased.example could alias the apex by
adding one additional record:</t>
          <artwork><![CDATA[
          <sourcecode type="dns-rr"><![CDATA[
@               7200 IN HTTPS 0 pool.svc.example.
]]></artwork>
]]></sourcecode>
          <t>With this record in place, HTTPS-RR-aware clients will use the same
server pool for aliased.example and www.aliased.example.  (They will
also upgrade "http://aliased.example/..." to "https".)  Non-HTTPS-RR-aware
clients will just ignore the new record.</t>
          <t>Similar to CNAME, HTTPS RRs have no impact on the origin name.
When connecting, clients will continue to treat the authoritative
origins as "https://www.aliased.example" and "https://aliased.example",
respectively, and will validate TLS server certificates accordingly.</t>
        </section>
        <section anchor="parameter-binding">
          <name>Parameter binding</name> Binding</name>
          <t>Suppose that svc.example's primary server pool supports HTTP/3, HTTP/3 but its
backup server pool does not.  This can be expressed in the following form:</t>
          <artwork><![CDATA[
          <sourcecode type="dns-rr"><![CDATA[
$ORIGIN svc.example. ; A hosting provider. provider
pool  7200 IN HTTPS 1 . alpn=h2,h3
              HTTPS 2 backup alpn=h2 port=8443
pool   300 IN A        192.0.2.2
              AAAA     2001:db8::2
backup 300 IN A        192.0.2.3
              AAAA     2001:db8::3
]]></artwork>
]]></sourcecode>
          <t>This configuration is entirely compatible with the "Apex "apex aliasing" example,
whether the client supports HTTPS RRs or not.  If the client does support
HTTPS RRs, all connections will be upgraded to HTTPS, and clients will
use HTTP/3 if they can.  Parameters are "bound" to each server pool, so
each server pool can have its own protocol, port number, etc.</t>
        </section>
        <section anchor="multicdn">
          <name>Multi-CDN</name>
          <name>Multi-CDN Configuration</name>
          <t>The HTTPS RR is intended to support HTTPS services operated by
multiple independent entities, such as different Content Delivery
Networks (CDNs) CDNs or different hosting providers.  This includes
the case where a service is migrated from one operator to another,
as well as the case where the service is multiplexed between
multiple operators for performance, redundancy, etc.</t>
          <t>This example shows such a configuration, with www.customer.example
having different DNS responses to different queries, either over time
or due to logic within the authoritative DNS server:</t>
          <artwork><![CDATA[
          <sourcecode type="dns-rr"><![CDATA[
 ; This zone contains/returns different CNAME records
 ; at different points-in-time. points in time.  The RRset for "www" can
 ; only ever contain a single CNAME.

 ; Sometimes the zone has:
 $ORIGIN customer.example.  ; A Multi-CDN multi-CDN customer domain
 www 900 IN CNAME cdn1.svc1.example.

 ; and other times it contains:
 $ORIGIN customer.example.
 www 900 IN CNAME customer.svc2.example.

 ; and yet other times it contains:
 $ORIGIN customer.example.
 www 900 IN CNAME cdn3.svc3.example.

 ; With the following remaining constant and always included:
 $ORIGIN customer.example.  ; A Multi-CDN multi-CDN customer domain
 ; The apex is also aliased to www to match its configuration configuration.
 @     7200 IN HTTPS 0 www
 ; Non-HTTPS-aware clients use non-CDN IPs IPs.
               A    203.0.113.82
               AAAA 2001:db8:203::2

 ; Resolutions following the cdn1.svc1.example
 ; path use these records.
 ; This CDN uses a different alternative service for HTTP/3.
 $ORIGIN svc1.example.  ; domain for CDN 1
 cdn1     1800 IN HTTPS 1 h3pool alpn=h3
                  HTTPS 2 . alpn=h2
                  A    192.0.2.2
                  AAAA 2001:db8:192::4
 h3pool 300 IN A 192.0.2.3
            AAAA 2001:db8:192:7::3

 ; Resolutions following the customer.svc2.example
 ; path use these records.
 ; Note that this CDN only supports HTTP/2.
 $ORIGIN svc2.example. ; domain operated by CDN 2
 customer 300 IN HTTPS 1 . alpn=h2
           60 IN A    198.51.100.2
                 A    198.51.100.3
                 A    198.51.100.4
                 AAAA 2001:db8:198::7
                 AAAA 2001:db8:198::12

 ; Resolutions following the cdn3.svc3.example
 ; path use these records.
 ; Note that this CDN has no HTTPS records.
 $ORIGIN svc3.example. ; domain operated by CDN 3
 cdn3      60 IN A    203.0.113.8
                 AAAA 2001:db8:113::8
]]></artwork>
]]></sourcecode>
          <t>Note that in the above example, the different CDNs have different
configurations and different capabilities, but clients will use HTTPS RRs
as a bound-together unit.</t>
          <t>Domain owners should be cautious when using a multi-CDN configuration, as it
introduces a number of complexities highlighted by this example:</t>
          <ul spacing="normal">
            <li>If CDN 1 supports a desired protocol or feature, feature and CDN 2 does not, the
client is vulnerable to
downgrade by a network adversary who forces clients to get CDN 2 records.</li>
            <li>Aliasing the apex to its subdomain simplifies the zone file but likely
increases resolution latency, especially when using a non-HTTPS-aware
recursive resolver.  An alternative would be to alias the zone
apex directly to a name managed by a CDN.</li>
            <li>The A, AAAA, and HTTPS resolutions are independent lookups, so resolvers may
observe and follow different CNAMEs to different CDNs.
Clients may thus find that the A and AAAA responses do not correspond to the
TargetName in the HTTPS response, and response; these clients will need to perform additional
queries to retrieve the correct IP addresses.
Including ipv6hint and ipv4hint will reduce the performance
impact of this case.</li>
            <li>If not all CDNs publish HTTPS records, clients will sometimes
receive NODATA for HTTPS queries (as with cdn3.svc3.example above), above)
but could receive A/AAAA records from a different CDN.  Clients will
attempt to connect to this CDN without the benefit of its HTTPS
records.</li>
          </ul>
        </section>
        <section anchor="non-http-uses">
          <name>Non-HTTP uses</name> Uses</name>
          <t>For protocols other than HTTP, the SVCB RR and an Attrleaf label <xref target="Attrleaf"/> target="RFC8552"/>
will be used.  For example, to reach an example resource of
"baz://api.example.com:8765", the following SVCB
record would be used to alias it to "svc4-baz.example.net." "svc4-baz.example.net.",
which in-turn in turn could return AAAA/A records and/or SVCB
records in ServiceMode:</t>
          <artwork><![CDATA[
          <sourcecode type="dns-rr"><![CDATA[
_8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net.
]]></artwork>
]]></sourcecode>
          <t>HTTPS RRs use similar Attrleaf labels if the origin contains
a non-default port.</t>
        </section>
      </section>
    </section>
    <section anchor="other-standards">
      <name>Interaction with other standards</name> Other Standards</name>
      <t>This standard is intended to reduce connection latency and
improve user privacy.  Server operators implementing this standard
SHOULD
<bcp14>SHOULD</bcp14> also implement TLS 1.3 <xref target="RFC8446"/> and OCSP
Online Certificate Status Protocol (OCSP) Stapling (i.e., Certificate Status
Request in <xref target="RFC6066"/>, target="RFC6066" section="8" sectionFormat="of"/>),
both of which confer substantial performance and privacy
benefits when used in combination with SVCB records.</t>
      <t>To realize the greatest privacy benefits, this proposal is intended for
use over a privacy-preserving DNS transport (like DNS over TLS
<xref target="DoT"/> target="RFC7858"/> or DNS over HTTPS <xref target="DoH"/>). target="RFC8484"/>).
However, performance improvements, and some modest privacy improvements,
are possible without the use of those standards.</t>
      <t>Any specification for the use of SVCB with a protocol MUST <bcp14>MUST</bcp14> have an entry for its
scheme under the SVCB RR type in the IANA DNS Underscore Global "Underscored and Globally Scoped Entry
Registry DNS Node Names" registry <xref target="Attrleaf"/>. target="RFC8552"/>.  The scheme MUST <bcp14>MUST</bcp14> have an entry in the IANA URI Schemes
Registry "Uniform Resource Identifier (URI) Schemes" registry <xref target="RFC7595"/>, target="RFC7595"/> and MUST <bcp14>MUST</bcp14> have a defined specification for use
with SVCB.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>SVCB/HTTPS RRs permit distribution over untrusted
channels, and clients are REQUIRED <bcp14>REQUIRED</bcp14> to verify that the alternative endpoint
is authoritative for the service (similar to <xref section="2.1" sectionFormat="of" target="AltSvc"/>). target="RFC7838"/>).
Therefore, DNSSEC signing and validation are OPTIONAL <bcp14>OPTIONAL</bcp14> for publishing
and using SVCB and HTTPS RRs.</t>
      <t>Clients MUST <bcp14>MUST</bcp14> ensure that their DNS cache is partitioned for each local
network, or flushed on network changes, to prevent a local adversary in one
network from implanting a forged DNS record that allows them to
track users or hinder their connections after they leave that network.</t>
      <t>An attacker who can prevent SVCB resolution can deny clients any associated
security benefits.  A hostile recursive resolver can always deny service to
SVCB queries, but network intermediaries can often prevent resolution as well,
even when the client and recursive resolver validate DNSSEC and use a secure
transport.  These downgrade attacks can prevent the "https" upgrade provided by
the HTTPS RR (<xref target="hsts"/>), target="hsts"/>) and can disable any other protections coordinated via
SvcParams.  To prevent downgrades, <xref target="client-failures"/>
recommends that clients abandon the connection attempt when such an attack is
detected.</t>
      <t>A hostile DNS intermediary might forge AliasMode "." records (<xref target="aliasdot"/>) as
a way to block clients from accessing particular services.  Such an adversary
could already block entire domains by forging erroneous responses, but this
mechanism allows them to target particular protocols or ports within a domain.
Clients that might be subject to such attacks SHOULD <bcp14>SHOULD</bcp14> ignore AliasMode "."
records.</t>
      <t>A hostile DNS intermediary or origin authoritative server can return SVCB records indicating any IP
address and port number, including IP addresses inside the local network and
port numbers assigned to internal services.  If the attacker can influence the
client's payload (e.g. (e.g., TLS session ticket contents), contents) and an internal service
has a sufficiently lax parser, it's possible that the attacker could gain
unintended access. access to the
internal service.  (The same concerns apply to SRV records, HTTP Alt-Svc,
and HTTP redirects.)  As a mitigation, SVCB mapping documents SHOULD <bcp14>SHOULD</bcp14> indicate
any port number restrictions that are appropriate for the supported transports.</t>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>Standard address queries reveal the user's intent to access a particular
domain.  This information is visible to the recursive resolver, and to
many other parties when plaintext DNS transport is used.  SVCB queries,
like queries for SRV records and other specific RR types, additionally
reveal the user's intent to use a particular protocol.  This is not
normally sensitive information, but it should be considered when adding
SVCB support in a new context.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="svcb-rrtype">
        <name>SVCB RRType</name>
        <t>This document defines a RR Type</name>

        <t>IANA has registered the following new DNS RR type, SVCB, whose value 64 has
been allocated by IANA from type in the "Resource Record (RR) TYPEs"
registry on the "Domain Name System (DNS) Parameters" page:</t>
        <ul spacing="normal">
          <li>Type: SVCB</li>
          <li>Value: 64</li>
          <li>Meaning: General Purpose Service Binding</li>
          <li>Reference: This document</li>
        </ul>
        <dl spacing="compact">
          <dt>Type:</dt><dd>SVCB</dd>
          <dt>Value:</dt><dd>64</dd>
          <dt>Meaning:</dt><dd>General-purpose service binding</dd>
          <dt>Reference:</dt><dd>RFC 9460</dd>
	</dl>
      </section>
      <section anchor="https-rrtype">
        <name>HTTPS RRType</name>
        <t>This document defines a RR Type</name>

   <t>IANA has registered the following new DNS RR type, "HTTPS", whose value 65 has
been allocated by IANA from type
   in the "Resource Record (RR) TYPEs" registry
   on the "Domain Name System (DNS) Parameters" page:</t>
        <ul spacing="normal">
          <li>Type: HTTPS</li>
          <li>Value: 65</li>
          <li>Meaning: Service Binding

        <dl spacing="compact">
          <dt>Type:</dt><dd>HTTPS</dd>
          <dt>Value:</dt><dd>65</dd>
          <dt>Meaning:</dt><dd>SVCB-compatible type for use with HTTP</li>
          <li>Reference: This document</li>
        </ul> HTTP</dd>
          <dt>Reference:</dt><dd>RFC 9460</dd>
	</dl>
      </section>
      <section anchor="svcparamregistry">
        <name>New registry Registry for Service Parameters</name>
        <t>IANA is requested to create a new registry, entitled has created the "Service Parameter Keys (SvcParamKeys)". (SvcParamKeys)"
registry in the "Domain Name System (DNS) Parameters" category
on a new page entitled "DNS Service Bindings (SVCB)".  This registry
defines the namespace
for parameters, including string representations and numeric
SvcParamKey values.  This registry is shared with other SVCB-compatible
RR types, such as the HTTPS RR.</t>
        <t>ACTION: create this registry, on a new page entitled
"DNS Service Bindings (SVCB)" under the "Domain Name System (DNS) Parameters"
category.</t>
        <section anchor="procedure">
          <name>Procedure</name>
          <t>A registration MUST <bcp14>MUST</bcp14> include the following fields:</t>
          <ul spacing="normal">
            <li>Number: wire format
          <dl spacing="compact">
            <dt>Number:</dt><dd>Wire-format numeric identifier (range 0-65535)</li>
            <li>Name: unique 0-65535)</dd>
            <dt>Name:</dt><dd>Unique presentation name</li>
            <li>Meaning: a name</dd>
            <dt>Meaning:</dt><dd>A short description</li>
            <li>Format Reference: pointer to description</dd>
            <dt>Reference:</dt><dd>Location of specification text</li>
            <li>Change Controller: Person or registration source</dd>
            <dt>Change Controller:</dt><dd>Person or entity, with contact information if appropriate.</li>
          </ul> appropriate</dd>
	  </dl>
          <t>The characters in the registered Name MUST field entry <bcp14>MUST</bcp14> be lower-case lowercase alphanumeric or "-"
(<xref target="presentation"/>).  The name MUST NOT <bcp14>MUST NOT</bcp14> start with "key" or "invalid".</t>
          <t>New
          <t>The registration policy for new entries in this registry are subject to an is Expert Review registration
policy (<xref section="4.5" sectionFormat="comma" target="RFC8126"/>).  The designated expert MUST <bcp14>MUST</bcp14> ensure that
the Format Reference reference is stable and publicly available, available and that it specifies
how to convert the SvcParamValue's presentation format to wire format.  The
Format Reference MAY
reference <bcp14>MAY</bcp14> be any individual's Internet-Draft, Internet-Draft or a document from
any other source with similar assurances of stability and availability.
An entry MAY <bcp14>MAY</bcp14> specify a Format Reference reference of
the form "Same as (other key Name)" name)" if it uses the same presentation and wire
formats as an existing key.</t> key.
</t>
          <t>This arrangement supports the development of new parameters while ensuring that
zone files can be made interoperable.</t>
        </section>
        <section anchor="iana-keys">
          <name>Initial contents</name> Contents</name>
          <t>The "Service Binding (SVCB) Parameter Registry" shall initially
be Keys (SvcParamKeys)" registry has been
populated with the registrations below:</t> following initial registrations:</t>

          <table>
            <thead>
              <tr>
                <th align="left">Number</th>
                <th align="left">Name</th>
                <th align="left">Meaning</th>
                <th align="left">Format Reference</th> align="left">Reference</th>
                <th align="left">Change Controller</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">0</td>
                <td align="left">mandatory</td>
                <td align="left">Mandatory keys in this RR</td>
                <td align="left">(This document) align="left">RFC 9460, <xref target="mandatory"/></td>
                <td align="left">IETF</td>
              </tr>
              <tr>
                <td align="left">1</td>
                <td align="left">alpn</td>
                <td align="left">Additional supported protocols</td>
                <td align="left">(This document) align="left">RFC 9460, <xref target="alpn-key"/></td>
                <td align="left">IETF</td>
              </tr>
              <tr>
                <td align="left">2</td>
                <td align="left">no-default-alpn</td>
                <td align="left">No support for default protocol</td>
                <td align="left">(This document) align="left">RFC 9460, <xref target="alpn-key"/></td>
                <td align="left">IETF</td>
              </tr>
              <tr>
                <td align="left">3</td>
                <td align="left">port</td>
                <td align="left">Port for alternative endpoint</td>
                <td align="left">(This document) align="left">RFC 9460, <xref target="svcparamkeys-port"/></td>
                <td align="left">IETF</td>
              </tr>
              <tr>
                <td align="left">4</td>
                <td align="left">ipv4hint</td>
                <td align="left">IPv4 address hints</td>
                <td align="left">(This document) align="left">RFC 9460, <xref target="svcparamkeys-iphints"/></td>
                <td align="left">IETF</td>
              </tr>
              <tr>
                <td align="left">5</td>
                <td align="left">ech</td>
                <td align="left">RESERVED (will be used (held for ECH)</td> Encrypted ClientHello)</td>
                <td align="left">N/A</td>
                <td align="left">IETF</td>
              </tr>
              <tr>
                <td align="left">6</td>
                <td align="left">ipv6hint</td>
                <td align="left">IPv6 address hints</td>
                <td align="left">(This document) align="left">RFC 9460, <xref target="svcparamkeys-iphints"/></td>
                <td align="left">IETF</td>
              </tr>
              <tr>
                <td align="left">65280-65534</td>
                <td align="left">N/A</td>
                <td align="left">Private align="left">Reserved for Private Use</td>
                <td align="left">(This document)</td> align="left">RFC 9460</td>
                <td align="left">IETF</td>
              </tr>
              <tr>
                <td align="left">65535</td>
                <td align="left">N/A</td>
                <td align="left">Reserved ("Invalid key")</td>
                <td align="left">(This document)</td> align="left">RFC 9460</td>
                <td align="left">IETF</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="other-registry-updates">
        <name>Other registry updates</name> Registry Updates</name>
        <t>Per <xref target="Attrleaf"/>, please add target="RFC8552"/>, the following entry has been added to the DNS Underscore
Global "Underscored and Globally Scoped Entry Registry:</t> DNS Node Names" registry:</t>
        <table>
          <thead>
            <tr>
              <th align="left">RR TYPE</th> Type</th>
              <th align="left">_NODE NAME</th>
              <th align="left">Meaning</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">HTTPS</td>
              <td align="left">_https</td>
              <td align="left">HTTPS SVCB info</td>
              <td align="left">(This document)</td> align="left">RFC 9460</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="acknowledgments-and-related-proposals">
      <name>Acknowledgments and Related Proposals</name>
      <t>There have been a wide range of proposed solutions over the years to
the "CNAME at the Zone Apex" challenge proposed.  These include
<xref target="I-D.bellis-dnsop-http-record"/>,
<xref target="I-D.ietf-dnsop-aname"/>, and others.</t>
      <t>Thank you to Ian Swett, Ralf Weber, Jon Reed,
Martin Thomson, Lucas Pardue, Ilari Liusvaara,
Tim Wicinski, Tommy Pauly, Chris Wood, David Benjamin,
Mark Andrews, Emily Stark, Eric Orth, Kyle Rose,
Craig Taylor, Dan McArdle, Brian Dickson,
Willem Toorop, Pieter Lexis, Puneet Sood,
Olivier Poitrey, Mashooq Muhaimen,
Tom Carpay, and many others for their feedback
and suggestions on this draft.</t>
    </section>
  </middle>
  <back>

<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC8552" to="Attrleaf"/>
<displayreference target="RFC8305" to="HappyEyeballsV2"/>
<displayreference target="RFC7858" to="DoT"/>
<displayreference target="RFC8484" to="DoH"/>
<displayreference target="RFC7301" to="ALPN"/>
<displayreference target="RFC6455" to="WebSocket"/>
<displayreference target="I-D.ietf-tls-esni" to="ECH"/>
<displayreference target="RFC9114" to="HTTP/3"/>
<displayreference target="RFC2782" to="SRV"/>
<displayreference target="RFC6797" to="HSTS"/>
<displayreference target="RFC7838" to="AltSvc"/>
<displayreference target="RFC8499" to="DNSTerm"/>
<displayreference target="RFC3986" to="URI"/>
<displayreference target="RFC6672" to="DNAME"/>
<displayreference target="I-D.bellis-dnsop-http-record" to="HTTP-DNS-RR"/>
<displayreference target="I-D.ietf-dnsop-aname" to="ANAME-DNS-RR"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="HTTP">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="Roy T. Fielding" initials="R. T." surname="Fielding">
              <organization>Adobe</organization>
            </author>
            <author fullname="Mark Nottingham" initials="M." surname="Nottingham">
              <organization>Fastly</organization>
            </author>
            <author fullname="Julian Reschke" initials="J." surname="Reschke">
              <organization>greenbytes GmbH</organization>
            </author>
            <date day="12" month="September" year="2021"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, 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.

 This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.
              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-19"/>
        </reference>
        <reference anchor="Attrleaf">
          <front>
            <title>Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves</title>
            <author fullname="D. Crocker" initials="D." surname="Crocker">
              <organization/>
            </author>
            <date month="March" year="2019"/>
            <abstract>
              <t>Formally, any DNS Resource Record (RR) may occur under any domain name.  However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies.  The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name").  The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch.  This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="222"/>
          <seriesInfo name="RFC" value="8552"/>
          <seriesInfo name="DOI" value="10.17487/RFC8552"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  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="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <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 protocol  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="RFC1035">
          <front>
            <title>Domain names - implementation and specification</title>
            <author fullname="P. Mockapetris" initials="P." surname="Mockapetris">
              <organization/>
            </author>
            <date month="November" year="1987"/>
            <abstract>
              <t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System.  It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1035"/>
          <seriesInfo name="DOI" value="10.17487/RFC1035"/>
        </reference>
        <reference anchor="RFC5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker">
              <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 Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [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="RFC1034">
          <front>
            <title>Domain names - concepts and facilities</title>
            <author fullname="P. Mockapetris" initials="P." surname="Mockapetris">
              <organization/>
            </author>
            <date month="November" year="1987"/>
            <abstract>
              <t>This RFC is the revised basic definition of The Domain Name System.  It obsoletes RFC-882.  This memo describes the domain style names and their used for host address look up and electronic mail forwarding.  It discusses the clients and servers in the domain name system and the protocol used between them.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1034"/>
          <seriesInfo name="DOI" value="10.17487/RFC1034"/>
        </reference>
        <reference anchor="HappyEyeballsV2">
          <front>
            <title>Happy Eyeballs Version 2: Better Connectivity Using Concurrency</title>
            <author fullname="D. Schinazi" initials="D." surname="Schinazi">
              <organization/>
            </author>
            <author fullname="T. Pauly" initials="T." surname="Pauly">
              <organization/>
            </author>
            <date month="December" year="2017"/>
            <abstract>
              <t>Many communication protocols operating over the modern Internet use hostnames.  These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics.  Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly.  This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs".  This document obsoletes the original algorithm description in RFC 6555.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8305"/>
          <seriesInfo name="DOI" value="10.17487/RFC8305"/>
        </reference>
        <reference anchor="DoT">
          <front>
            <title>Specification for DNS over Transport Layer Security (TLS)</title>
            <author fullname="Z. Hu" initials="Z." surname="Hu">
              <organization/>
            </author>
            <author fullname="L. Zhu" initials="L." surname="Zhu">
              <organization/>
            </author>
            <author fullname="J. Heidemann" initials="J." surname="Heidemann">
              <organization/>
            </author>
            <author fullname="A. Mankin" initials="A." surname="Mankin">
              <organization/>
            </author>
            <author fullname="D. Wessels" initials="D." surname="Wessels">
              <organization/>
            </author>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <date month="May" year="2016"/>
            <abstract>
              <t>This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS.  Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626.  In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t>
              <t>This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group.  It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7858"/>
          <seriesInfo name="DOI" value="10.17487/RFC7858"/>
        </reference>
        <reference anchor="DoH">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <author fullname="P. McManus" initials="P." surname="McManus">
              <organization/>
            </author>
            <date month="October" year="2018"/>
            <abstract>
              <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS.  Each DNS query-response pair is mapped into an HTTP exchange.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8484"/>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
        </reference>
        <reference anchor="RFC7231">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding">
              <organization/>
            </author>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7231"/>
          <seriesInfo name="DOI" value="10.17487/RFC7231"/>
        </reference>
        <reference anchor="RFC1928">
          <front>
            <title>SOCKS Protocol Version 5</title>
            <author fullname="M. Leech" initials="M." surname="Leech">
              <organization/>
            </author>
            <author fullname="M. Ganis" initials="M." surname="Ganis">
              <organization/>
            </author>
            <author fullname="Y. Lee" initials="Y." surname="Lee">
              <organization/>
            </author>
            <author fullname="R. Kuris" initials="R." surname="Kuris">
              <organization/>
            </author>
            <author fullname="D. Koblas" initials="D." surname="Koblas">
              <organization/>
            </author>
            <author fullname="L. Jones" initials="L." surname="Jones">
              <organization/>
            </author>
            <date month="March" year="1996"/>
            <abstract>
              <t>This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1928"/>
          <seriesInfo name="DOI" value="10.17487/RFC1928"/>
        </reference>
        <reference anchor="RFC3597">
          <front>
            <title>Handling of Unknown DNS Resource Record (RR) Types</title>
            <author fullname="A. Gustafsson" initials="A." surname="Gustafsson">
              <organization/>
            </author>
            <date month="September" year="2003"/>
            <abstract>
              <t>Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software.  This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3597"/>
          <seriesInfo name="DOI" value="10.17487/RFC3597"/>
        </reference>
        <reference anchor="RFC6147">
          <front>
            <title>DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers</title>
            <author fullname="M. Bagnulo" initials="M." surname="Bagnulo">
              <organization/>
            </author>
            <author fullname="A. Sullivan" initials="A." surname="Sullivan">
              <organization/>
            </author>
            <author fullname="P. Matthews" initials="P." surname="Matthews">
              <organization/>
            </author>
            <author fullname="I. van Beijnum" initials="I." surname="van Beijnum">
              <organization/>
            </author>
            <date month="April" year="2011"/>
            <abstract>
              <t>DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs.  This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6147"/>
          <seriesInfo name="DOI" value="10.17487/RFC6147"/>
        </reference>
        <reference anchor="RFC3225">
          <front>
            <title>Indicating Resolver Support of DNSSEC</title>
            <author fullname="D. Conrad" initials="D." surname="Conrad">
              <organization/>
            </author>
            <date month="December" year="2001"/>
            <abstract>
              <t>In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs.  This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3225"/>
          <seriesInfo name="DOI" value="10.17487/RFC3225"/>
        </reference>
        <reference anchor="RFC2181">
          <front>
            <title>Clarifications to the DNS Specification</title>
            <author fullname="R. Elz" initials="R." surname="Elz">
              <organization/>
            </author>
            <author fullname="R. Bush" initials="R." surname="Bush">
              <organization/>
            </author>
            <date month="July" year="1997"/>
            <abstract>
              <t>This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2181"/>
          <seriesInfo name="DOI" value="10.17487/RFC2181"/>
        </reference>
        <reference anchor="RFC7871">
          <front>
            <title>Client Subnet in DNS Queries</title>
            <author fullname="C. Contavalli" initials="C." surname="Contavalli">
              <organization/>
            </author>
            <author fullname="W. van der Gaast" initials="W." surname="van der Gaast">
              <organization/>
            </author>
            <author fullname="D. Lawrence" initials="D." surname="Lawrence">
              <organization/>
            </author>
            <author fullname="W. Kumari" initials="W." surname="Kumari">
              <organization/>
            </author>
            <date month="May" year="2016"/>
            <abstract>
              <t>This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached.  Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7871"/>
          <seriesInfo name="DOI" value="10.17487/RFC7871"/>
        </reference>
        <reference anchor="ALPN">
          <front>
            <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
            <author fullname="S. Friedl" initials="S." surname="Friedl">
              <organization/>
            </author>
            <author fullname="A. Popov" initials="A." surname="Popov">
              <organization/>
            </author>
            <author fullname="A. Langley" initials="A." surname="Langley">
              <organization/>
            </author>
            <author fullname="E. Stephan" initials="E." surname="Stephan">
              <organization/>
            </author>
            <date month="July" year="2014"/>
            <abstract>
              <t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7301"/>
          <seriesInfo name="DOI" value="10.17487/RFC7301"/>
        </reference>
        <reference anchor="RFC5952">
          <front>
            <title>A Recommendation for IPv6 Address Text Representation</title>
            <author fullname="S. Kawamura" initials="S." surname="Kawamura">
              <organization/>
            </author>
            <author fullname="M. Kawashima" initials="M." surname="Kawashima">
              <organization/>
            </author>
            <date month="August" year="2010"/>
            <abstract>
              <t>As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text.  While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users.  This document defines a canonical textual representation format.  It does not define a format for internal storage, such as within an application or database.  It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5952"/>
          <seriesInfo name="DOI" value="10.17487/RFC5952"/>
        </reference>
        <reference anchor="RFC4001">
          <front>
            <title>Textual Conventions for Internet Network Addresses</title>
            <author fullname="M. Daniele" initials="M." surname="Daniele">
              <organization/>
            </author>
            <author fullname="B. Haberman" initials="B." surname="Haberman">
              <organization/>
            </author>
            <author fullname="S. Routhier" initials="S." surname="Routhier">
              <organization/>
            </author>
            <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
              <organization/>
            </author>
            <date month="February" year="2005"/>
            <abstract>
              <t>This MIB module defines textual conventions to represent commonly used Internet network layer addressing information.  The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4001"/>
          <seriesInfo name="DOI" value="10.17487/RFC4001"/>
        </reference>
        <reference anchor="RFC7050">
          <front>
            <title>Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis</title>
            <author fullname="T. Savolainen" initials="T." surname="Savolainen">
              <organization/>
            </author>
            <author fullname="J. Korhonen" initials="J." surname="Korhonen">
              <organization/>
            </author>
            <author fullname="D. Wing" initials="D." surname="Wing">
              <organization/>
            </author>
            <date month="November" year="2013"/>
            <abstract>
              <t>This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network.  The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.".  The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7050"/>
          <seriesInfo name="DOI" value="10.17487/RFC7050"/>
        </reference>
        <reference anchor="WebSocket">
          <front>
            <title>The WebSocket Protocol</title>
            <author fullname="I. Fette" initials="I." surname="Fette">
              <organization/>
            </author>
            <author fullname="A. Melnikov" initials="A." surname="Melnikov">
              <organization/>
            </author>
            <date month="December" year="2011"/>
            <abstract>
              <t>The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code.  The security model used for this is the origin-based security model commonly used by web browsers.  The protocol consists of an opening handshake followed by basic message framing, layered over TCP.  The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or &lt;iframe&gt;s and long polling).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6455"/>
          <seriesInfo name="DOI" value="10.17487/RFC6455"/>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC6066">
          <front>
            <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd">
              <organization/>
            </author>
            <date month="January" year="2011"/>
            <abstract>
              <t>This document provides specifications for existing TLS extensions.  It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2".  The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6066"/>
          <seriesInfo name="DOI" value="10.17487/RFC6066"/>
        </reference>
        <reference anchor="RFC7595">
          <front>
            <title>Guidelines and Registration Procedures for URI Schemes</title>
            <author fullname="D. Thaler" initials="D." role="editor" surname="Thaler">
              <organization/>
            </author>
            <author fullname="T. Hansen" initials="T." surname="Hansen">
              <organization/>
            </author>
            <author fullname="T. Hardie" initials="T." surname="Hardie">
              <organization/>
            </author>
            <date month="June" year="2015"/>
            <abstract>
              <t>This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes.  It obsoletes RFC 4395.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="35"/>
          <seriesInfo name="RFC" value="7595"/>
          <seriesInfo name="DOI" value="10.17487/RFC7595"/>
        </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 constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations 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 describing the conditions under which new values should be assigned, as well as when 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 Considerations 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 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>

<!-- draft-ietf-httpbis-semantics (RFC 9110) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1928.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3597.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3225.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7871.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5952.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4001.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7050.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6455.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7595.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

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

        <reference anchor="FETCH" target="https://fetch.spec.whatwg.org/">
          <front>
            <title>Fetch Living Standard</title>
            <author>
              <organization/>
            </author>
            <date year="2020" month="May"/>
          </front>
        </reference>
        <reference anchor="ECH">
          <front>
            <title>TLS Encrypted Client Hello</title>
            <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
              <organization>RTFM, Inc.</organization>
            </author>
            <author fullname="Kazuho Oku" initials="K." surname="Oku">
              <organization>Fastly</organization>
            </author>
            <author fullname="Nick Sullivan" initials="N." surname="Sullivan">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="3" month="October" year="2022"/>
            <abstract>
              <t>   This document describes a mechanism in Transport Layer Security (TLS)
   for encrypting a ClientHello message under a server public key.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/tlswg/draft-ietf-tls-esni
   (https://github.com/tlswg/draft-ietf-tls-esni).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-15"/>
        </reference>
        <reference anchor="HTTP3">
          <front>
            <title>HTTP/3</title>
            <author fullname="Mike Bishop" initials="M." surname="Bishop">
              <organization>Akamai</organization>
              <organization>WHATWG</organization>
            </author>
            <date day="2" month="February" year="2021"/>
            <abstract>
              <t>The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment.  This document describes a mapping of HTTP semantics over QUIC.  This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.
              </t>
            </abstract> year="2023" month="October"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
        </reference>

        <reference anchor="SRV"> anchor="FETCH-WEBSOCKETS" target="https://websockets.spec.whatwg.org/">
          <front>
            <title>A DNS RR for specifying the location of services (DNS SRV)</title>
            <author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen">
              <organization/>
            </author>
            <author fullname="P. Vixie" initials="P." surname="Vixie">
              <organization/>
            </author>
            <author fullname="L. Esibov" initials="L." surname="Esibov">
              <organization/>
            </author>
            <date month="February" year="2000"/>
            <abstract>
              <t>This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2782"/>
          <seriesInfo name="DOI" value="10.17487/RFC2782"/>
        </reference>
        <reference anchor="HSTS">
          <front>
            <title>HTTP Strict Transport Security (HSTS)</title>
            <author fullname="J. Hodges" initials="J." surname="Hodges">
              <organization/>
            </author>
            <author fullname="C. Jackson" initials="C." surname="Jackson">
              <organization/>
            </author>
            <author fullname="A. Barth" initials="A." surname="Barth">
              <organization/>
            </author>
            <date month="November" year="2012"/>
            <abstract>
              <t>This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections.  This overall policy is referred to as HTTP Strict Transport Security (HSTS).  The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6797"/>
          <seriesInfo name="DOI" value="10.17487/RFC6797"/>
        </reference>
        <reference anchor="AltSvc">
          <front>
            <title>HTTP Alternative Services</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="P. McManus" initials="P." surname="McManus">
              <organization/>
            </author>
            <author fullname="J. Reschke" initials="J." surname="Reschke">
              <organization/>
            </author>
            <date month="April" year="2016"/>
            <abstract>
              <t>This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7838"/>
          <seriesInfo name="DOI" value="10.17487/RFC7838"/>
        </reference>
        <reference anchor="RFC6454">
          <front>
            <title>The Web Origin Concept</title>
            <author fullname="A. Barth" initials="A." surname="Barth">
              <organization/>
            </author>
            <date month="December" year="2011"/>
            <abstract>
              <t>This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents.  Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites.  In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string.  It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6454"/>
          <seriesInfo name="DOI" value="10.17487/RFC6454"/>
        </reference>
        <reference anchor="DNSTerm">
          <front>
            <title>DNS Terminology</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <author fullname="A. Sullivan" initials="A." surname="Sullivan">
              <organization/>
            </author>
            <author fullname="K. Fujiwara" initials="K." surname="Fujiwara">
              <organization/>
            </author>
            <date month="January" year="2019"/>
            <abstract>
              <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs.  The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined.  This document gives current definitions for many of the terms used in the DNS in a single document.</t>
              <t>This document obsoletes RFC 7719 and updates RFC 2308.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="219"/>
          <seriesInfo name="RFC" value="8499"/>
          <seriesInfo name="DOI" value="10.17487/RFC8499"/>
        </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/>
            <title>WebSockets Living Standard</title>
            <author>
              <organization>WHATWG</organization>
            </author>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t>
            </abstract> year="2023" month="September"/>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>

        <reference anchor="RFC1912"> anchor="BIND-CHECK-NAMES" target="https://bind9.readthedocs.io/en/v9.19.11/reference.html#namedconf-statement-check-names">
          <front>
            <title>Common DNS Operational and
            <title>BIND v9.19.11 Configuration Errors</title>
            <author fullname="D. Barr" initials="D." surname="Barr">
              <organization/>
            </author>
            <date month="February" year="1996"/>
            <abstract>
              <t>This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain.  This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1912"/>
          <seriesInfo name="DOI" value="10.17487/RFC1912"/>
        </reference>
        <reference anchor="DNAME">
          <front>
            <title>DNAME Redirection in the DNS</title>
            <author fullname="S. Rose" initials="S." surname="Rose">
              <organization/>
            </author>
            <author fullname="W. Wijngaards" initials="W." surname="Wijngaards">
              <organization/>
            </author>
            <date month="June" year="2012"/>
            <abstract>
              <t>The DNAME record provides redirection for a subtree of the domain name tree in the DNS.  That is, all names that end with a particular suffix are redirected to another part of the DNS.  This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6672"/>
          <seriesInfo name="DOI" value="10.17487/RFC6672"/>
        </reference>
        <reference anchor="I-D.bellis-dnsop-http-record">
          <front>
            <title>A DNS Resource Record for HTTP</title>
            <author fullname="Ray Bellis" initials="R." surname="Bellis"> Reference: "check-names"</title>
            <author>
              <organization>Internet Systems Consortium, Inc.</organization> Consortium</organization>
            </author>
            <date day="3" month="November" year="2018"/>
            <abstract>
              <t>   This document specifies an "HTTP" resource record type for the DNS to
   facilitate the lookup of the server hostname of HTTP(s) URIs.  It is
   intended to replace the use of CNAME records for this purpose, and in
   the process provides a solution for the inability of the DNS to allow
   a CNAME to be placed at the apex of a domain name.

              </t>
            </abstract> year="2023" month="September"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-bellis-dnsop-http-record-00"/>
        </reference>

<!-- draft-ietf-tls-esni (I-D Exists) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-esni.xml"/>

<!-- draft-ietf-quic-http (RFC 9114) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9114.xml"/>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6797.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7838.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6454.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1912.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6672.xml"/>

<!-- draft-bellis-dnsop-http-record (Expired) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.bellis-dnsop-http-record.xml"/>

<!-- draft-ietf-dnsop-aname (Expired) ("long way" to fix author initials) -->
<reference anchor="I-D.ietf-dnsop-aname">
   <front>
      <title>Address-specific DNS aliases (ANAME)</title>
      <author fullname="Tony Finch" initials="T." surname="Finch"> surname="Finch" fullname="Tony Finch">
         <organization>University of Cambridge</organization>
      </author>
      <author fullname="Evan Hunt" initials="E." surname="Hunt"> surname="Hunt" fullname="Evan Hunt">
         <organization>ISC</organization>
      </author>
      <author fullname="Peter van Dijk" initials="P." surname="van Dijk" fullname="Peter van Dijk">
         <organization>PowerDNS</organization>
      </author>
      <author fullname="Anthony Eden" initials="A." surname="Eden"> surname="Eden" fullname="Anthony Eden">
         <organization>DNSimple</organization>
      </author>
      <author initials="W." surname="Mekking" fullname="Matthijs Mekking" initials="W. M." surname="Mekking"> Mekking">
         <organization>ISC</organization>
      </author>
      <date day="8" month="July" year="2019"/>
            <abstract>
              <t>   This document defines the "ANAME" DNS RR type, to provide similar
   functionality to CNAME, but only for address queries.  Unlike CNAME,
   an ANAME can coexist with other record types.  The ANAME RR allows
   zone owners to make an apex domain name into an alias in a standards
   compliant manner.

              </t>
            </abstract> day="8" year="2019" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-aname-04"/> value="draft-ietf-dnsop-aname-04" />
</reference>

      </references>
    </references>
    <section anchor="decoding">
      <name>Decoding text Text in zone files</name> Zone Files</name>
      <t>DNS zone files are capable of representing arbitrary octet sequences in
basic ASCII text, using various delimiters and encodings.  The encodings, according to an algorithm
for decoding these character-strings is
defined in <xref section="5.1" sectionFormat="of" target="RFC1035"/>.
Here we summarize the
The following summarizes some allowed input inputs to that algorithm, using ABNF:</t>
      <artwork><![CDATA[
<sourcecode name="" type="abnf"><![CDATA[
; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\".
non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E
; non-digit is VCHAR minus DIGIT DIGIT.
non-digit   = %x21-2F / %x3A-7E
; dec-octet is a number 0-255 as a three-digit decimal number.
dec-octet   = ( "0" / "1" ) 2DIGIT /
              "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) )
escaped     = "\" ( non-digit / dec-octet )
contiguous  = 1*( non-special / escaped )
quoted      = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE
char-string = contiguous / quoted
]]></artwork>
]]></sourcecode>
      <t>The decoding algorithm allows <tt>char-string</tt> to represent any <tt>*OCTET</tt>,
using quoting to group values (e.g., those with internal whitespace), and
escaping to represent each non-printable octet as a single <tt>escaped</tt> sequence.
In this document, this algorithm is referred to as "character-string decoding".
The decoding", because
<xref target="RFC1035" sectionFormat="of" section="5.1"/> uses this
algorithm is the same as used by <tt>&lt;character-string&gt;</tt> in RFC 1035,
although to produce a <tt>&lt;character-string&gt;</tt>.  Note that while
the output length in this document of a <tt>&lt;character-string&gt;</tt> is not limited to 255 octets.</t> octets, the
character-string decoding algorithm can produce output of any length.</t>
      <section anchor="value-list">
        <name>Decoding a comma-separated list</name> Comma-Separated List</name>
        <t>In order to represent lists of items in zone files, this specification uses
comma-separated lists.  When the allowed items in the list cannot contain ","
or "\", this is trivial.  (For simplicity, empty items are not allowed.)
A value-list parser that splits on "," and prohibits items containing "\"
is sufficient to comply with all requirements in this document.  This
corresponds to the <tt>simple-comma-separated</tt> syntax:</t>
        <artwork><![CDATA[
<sourcecode name="" type="abnf"><![CDATA[
; item-allowed is OCTET minus "," and "\".
item-allowed           = %x00-2B / %x2D-5B / %x5D-FF
simple-item            = 1*item-allowed
simple-comma-separated = [simple-item *("," simple-item)]
]]></artwork>
]]></sourcecode>
        <t>For implementations that allow "," and "\" in item values, the following
escaping syntax applies:</t>
        <artwork><![CDATA[
<sourcecode name="" type="abnf"><![CDATA[
item            = 1*OCTET
escaped-item    = 1*(item-allowed / "\," / "\\")
comma-separated = [escaped-item *("," escaped-item)]
]]></artwork>
]]></sourcecode>
        <t>Decoding of value-lists happens after character-string decoding.
For example, consider these <tt>char-string</tt> SvcParamValues:</t>
        <artwork><![CDATA[
        <sourcecode type="test-vectors"><![CDATA[
"part1,part2,part3\\,part4\\\\"
part1\,\p\a\r\t2\044part3\092,part4\092\\
]]></artwork>
]]></sourcecode>
        <t>These inputs are equivalent: character-string decoding either of them would
produce the same <tt>value</tt>:</t>
        <artwork><![CDATA[
        <sourcecode type="test-vectors"><![CDATA[
part1,part2,part3\,part4\\
]]></artwork>
]]></sourcecode>
        <t>Applying comma-separated list decoding to this <tt>value</tt> would produce a list
of three <tt>item</tt>s:</t>
        <artwork><![CDATA[
        <sourcecode type="test-vectors"><![CDATA[
part1
part2
part3,part4\
]]></artwork>
]]></sourcecode>
      </section>
    </section>
    <section anchor="http-mapping-summary">
      <name>HTTP Mapping Summary</name>
      <t>This table serves as a non-normative summary of the HTTP mapping for SVCB
(<xref target="https"/>).  Future protocol mappings may provide a similar summary table.</t>

      <table>
        <thead>
          <tr>
            <th align="left"> </th>
            <th align="left"> </th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">
              <strong>Mapped scheme</strong></td>
            <td align="left">"https"</td>
          </tr>
          <tr>
            <td align="left">
              <strong>Other affected schemes</strong></td>
            <td align="left">"http", "wss", "ws", (other HTTP-based)</td>
          </tr>
          <tr>
            <td align="left">
              <strong>RR type</strong></td>
            <td align="left">HTTPS (65)</td>
          </tr>
          <tr>
            <td align="left">
              <strong>Name prefix</strong></td>
            <td align="left">None for port 443, else <tt>_$PORT._https</tt></td>
          </tr>
          <tr>
            <td align="left">
              <strong>Automatically Mandatory Keys</strong></td> mandatory keys</strong></td>
            <td align="left">
              <tt>port</tt>, <tt>no-default-alpn</tt></td>
          </tr>
          <tr>
            <td align="left">
              <strong>SvcParam defaults</strong></td>
            <td align="left">
              <tt>alpn</tt>: ["http/1.1"]</td>
          </tr>
          <tr>
            <td align="left">
              <strong>Special behaviors</strong></td>
            <td align="left">HTTP align="left">Upgrade from HTTP to HTTPS upgrade</td> HTTPS</td>
          </tr>
          <tr>
            <td align="left">
              <strong>Keys that records must include</strong></td>
            <td align="left">None</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="comparison-with-alternatives">
      <name>Comparison with alternatives</name> Alternatives</name>
      <t>The SVCB and HTTPS RR types closely resemble,
and are inspired by, some existing
record types and proposals.  A  One complaint with regarding all of the alternatives
is that web clients have seemed unenthusiastic about implementing
them.  The hope here is that by providing an extensible solution that
solves multiple problems we will overcome the this inertia and have a path
to achieve client implementation.</t>
      <section anchor="differences-from-the-srv-rr-type">
        <name>Differences from the SRV RR type</name> Type</name>
        <t>An SRV record <xref target="SRV"/> target="RFC2782"/> can perform a similar function similar
to that of the SVCB record,
informing a client to look in a different location for a service.
However, there are several differences:</t>
        <ul spacing="normal">
          <li>SRV records are typically mandatory, whereas SVCB is intended to be optional
when used with pre-existing protocols.</li>
          <li>SRV records cannot instruct the client to switch or upgrade
protocols, whereas SVCB can signal such an upgrade (e.g. (e.g., to
HTTP/2).</li>
          <li>SRV records are not extensible, whereas SVCB and HTTPS RRs
can be extended with new parameters.</li>
          <li>SRV records specify a "weight" for unbalanced randomized load-balancing. load balancing.
SVCB only supports balanced randomized load-balancing, load balancing, although weights
could be added via a future SvcParam.</li>
        </ul>
      </section>
      <section anchor="differences-from-the-proposed-http-record">
        <name>Differences from the proposed Proposed HTTP record</name> Record</name>
        <t>Unlike <xref target="I-D.bellis-dnsop-http-record"/>, this approach is
extensible to cover Alt-Svc and Encrypted ClientHello use-cases. use cases.  Like that
proposal, this addresses the zone apex zone-apex CNAME challenge.</t>
        <t>Like that proposal, it remains necessary to continue to include
address records at the zone apex for legacy clients.</t>
      </section>
      <section anchor="differences-from-the-proposed-aname-record">
        <name>Differences from the proposed Proposed ANAME record</name> Record</name>
        <t>Unlike <xref target="I-D.ietf-dnsop-aname"/>, this approach is extensible to
cover Alt-Svc and ECH use-cases. Encrypted ClientHello use cases.  This approach also does not
require any changes or special handling on either authoritative or
primary servers, beyond optionally returning in-bailiwick additional records.</t>
        <t>Like that proposal, this addresses the zone apex zone-apex CNAME challenge
for clients that implement this.</t>
        <t>However, with this SVCB proposal, it remains necessary to continue
to include address records at the zone apex for legacy clients.
If deployment of this standard is successful, the number of legacy clients
will fall over time.  As the number of legacy clients declines, the operational
effort required to serve these users without the benefit of SVCB indirection
should fall.  Server operators can easily observe how much traffic reaches this
legacy endpoint, endpoint and may remove the apex's address records if the observed legacy
traffic has fallen to negligible levels.</t>
      </section>
      <section anchor="comparison-with-separate-rr-types-for-aliasmode-and-servicemode">
        <name>Comparison with separate Separate RR types Types for AliasMode and ServiceMode</name>
        <t>Abstractly, functions of AliasMode and ServiceMode are independent,
so it might be tempting to specify them as separate RR types.  However,
this would result in a serious performance impairment, because clients
cannot rely on their recursive resolver to follow SVCB aliases (unlike
CNAME).  Thus, clients would have to issue queries for both RR types
in parallel, potentially at each step of the alias chain.  Recursive
resolvers that implement the specification would, upon receipt of a
ServiceMode query, emit both a ServiceMode query and an AliasMode query to
the authoritative. authoritative DNS server.  Thus, splitting the RR type would double, or in
some cases triple, the load on clients and servers, and would not
reduce implementation complexity.</t>
      </section>
    </section>
    <section anchor="test-vectors">
      <name>Test vectors</name> Vectors</name>
      <t>These test vectors only contain the RDATA portion of SVCB/HTTPS records in
presentation format, generic format (<xref target="RFC3597"/>) <xref target="RFC3597"/>, and wire format. The wire
format uses hexadecimal (\xNN) for each non-ascii non-ASCII byte. As the wireformat wire format is
long, it is broken into several lines.</t>
      <section anchor="aliasmode">
        <name>AliasMode</name>
        <figure>
          <name>AliasMode</name>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
example.com.   HTTPS   0 foo.example.com.

\# 19 (
00 00                                              ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
)

\x00\x00                                           # priority
\x03foo\x07example\x03com\x00                      # target
]]></artwork>
]]></sourcecode>
        </figure>
      </section>
      <section anchor="servicemode-1">
        <name>ServiceMode</name>
        <figure>
          <name>TargetName is Is "."</name>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
example.com.   SVCB   1 .

\# 3 (
00 01      ; priority
00         ; target (root label)
)

\x00\x01   # priority
\x00       # target, root label
]]></artwork> target (root label)
]]></sourcecode>
        </figure>
        <figure>
          <name>Specifies a port</name>
          <artwork><![CDATA[ Port</name>
          <sourcecode type="test-vectors"><![CDATA[
example.com.   SVCB   16 foo.example.com. port=53

\# 25 (
00 10                                              ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
00 03                                              ; key 3
00 02                                              ; length 2
00 35                                              ; value
)

\x00\x10                                           # priority
\x03foo\x07example\x03com\x00                      # target
\x00\x03                                           # key 3
\x00\x02                                           # length: length 2 bytes
\x00\x35                                           # value
]]></artwork>
]]></sourcecode>
        </figure>
        <figure>
          <name>A generic key Generic Key and unquoted value</name>
          <artwork><![CDATA[ Unquoted Value</name>
          <sourcecode type="test-vectors"><![CDATA[
example.com.   SVCB   1 foo.example.com. key667=hello

\# 28 (
00 01                                              ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
02 9b                                              ; key 667
00 05                                              ; length 5
68 65 6c 6c 6f                                     ; value
)

\x00\x01                                           # priority
\x03foo\x07example\x03com\x00                      # target
\x02\x9b                                           # key 667
\x00\x05                                           # length 5
hello                                              # value
]]></artwork>
]]></sourcecode>
        </figure>
        <figure>
          <name>A generic key Generic Key and quoted value Quoted Value with a decimal escape</name>
          <artwork><![CDATA[ Decimal Escape</name>
          <sourcecode type="test-vectors"><![CDATA[
example.com.   SVCB   1 foo.example.com. key667="hello\210qoo"

\# 32 (
00 01                                              ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
02 9b                                              ; key 667
00 09                                              ; length 9
68 65 6c 6c 6f d2 71 6f 6f                         ; value
)

\x00\x01                                           # priority
\x03foo\x07example\x03com\x00                      # target
\x02\x9b                                           # key 667
\x00\x09                                           # length 9
hello\xd2qoo                                       # value
]]></artwork>
]]></sourcecode>
        </figure>
        <figure>
          <name>Two quoted Quoted IPv6 hints</name>
          <artwork><![CDATA[ Hints</name>
          <sourcecode type="test-vectors"><![CDATA[
example.com.   SVCB   1 foo.example.com. (
                      ipv6hint="2001:db8::1,2001:db8::53:1"
                      )

\# 55 (
00 01                                              ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
00 06                                              ; key 6
00 20                                              ; length 32
20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01    ; first address
20 01 0d b8 00 00 00 00 00 00 00 00 00 53 00 01    ; second address
)

\x00\x01                                           # priority
\x03foo\x07example\x03com\x00                      # target
\x00\x06                                           # key 6
\x00\x20                                           # length 32
\x20\x01\x0d\xb8\x00\x00\x00\x00
     \x00\x00\x00\x00\x00\x00\x00\x01              # first address
\x20\x01\x0d\xb8\x00\x00\x00\x00
     \x00\x00\x00\x00\x00\x53\x00\x01              # second address
]]></artwork>
]]></sourcecode>
        </figure>
        <figure>
          <name>An IPv6 hint using Hint Using the embedded Embedded IPv4 syntax</name>
          <artwork><![CDATA[ Syntax</name>
          <sourcecode type="test-vectors"><![CDATA[
example.com.   SVCB   1 example.com. (
                        ipv6hint="2001:db8:122:344::192.0.2.33"
                        )
\# 35 (
00 01                                              ; priority
07 65 78 61 6d 70 6c 65 03 63 6f 6d 00             ; target
00 06                                              ; key 6
00 10                                              ; length 16
20 01 0d b8 01 22 03 44 00 00 00 00 c0 00 02 21    ; address
)

\x00\x01                                           # priority
\x07example\x03com\x00                             # target
\x00\x06                                           # key 6
\x00\x10                                           # length 16
\x20\x01\x0d\xb8\x01\x22\x03\x44
     \x00\x00\x00\x00\xc0\x00\x02\x21              # address
]]></artwork>
]]></sourcecode>
        </figure>
        <figure>
          <name>SvcParamKey ordering is arbitrary Ordering Is Arbitrary in presentation format Presentation Format but sorted Sorted in wire format</name>
          <artwork><![CDATA[ Wire Format</name>
          <sourcecode type="test-vectors"><![CDATA[
example.com.   SVCB   16 foo.example.org. (
                      alpn=h2,h3-19 mandatory=ipv4hint,alpn
                      ipv4hint=192.0.2.1
                      )

\# 48 (
00 10                                              ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target
00 00                                              ; key 0
00 04                                              ; param length 4
00 01                                              ; value: key 1
00 04                                              ; value: key 4
00 01                                              ; key 1
00 09                                              ; param length 9
02                                                 ; alpn length 2
68 32                                              ; alpn value
05                                                 ; alpn length 5
68 33 2d 31 39                                     ; alpn value
00 04                                              ; key 4
00 04                                              ; param length 4
c0 00 02 01                                        ; param value
)

\x00\x10                                           # priority
\x03foo\x07example\x03org\x00                      # target
\x00\x00                                           # key 0
\x00\x04                                           # param length 4
\x00\x01                                           # value: key 1
\x00\x04                                           # value: key 4
\x00\x01                                           # key 1
\x00\x09                                           # param length 9
\x02                                               # alpn length 2
h2                                                 # alpn value
\x05                                               # alpn length 5
h3-19                                              # alpn value
\x00\x04                                           # key 4
\x00\x04                                           # param length 4
\xc0\x00\x02\x01                                   # param value
]]></artwork>
]]></sourcecode>
        </figure>
        <figure>
          <name>An alpn value &quot;alpn&quot; Value with an escaped comma Escaped Comma and an escaped backslash Escaped Backslash in two presentation formats</name>
          <artwork><![CDATA[ Two Presentation Formats</name>
          <sourcecode type="test-vectors"><![CDATA[
example.com.   SVCB   16 foo.example.org. alpn="f\\\\oo\\,bar,h2"
example.com.   SVCB   16 foo.example.org. alpn=f\\\092oo\092,bar,h2

\# 35 (
00 10                                              ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target
00 01                                              ; key 1
00 0c                                              ; param length 12
08                                                 ; alpn length 8
66 5c 6f 6f 2c 62 61 72                            ; alpn value
02                                                 ; alpn length 2
68 32                                              ; alpn value
)

\x00\x10                                           # priority
\x03foo\x07example\x03org\x00                      # target
\x00\x01                                           # key 1
\x00\x0c                                           # param length 12
\x08                                               # alpn length 8
f\oo,bar                                           # alpn value
\x02                                               # alpn length 2
h2                                                 # alpn value
]]></artwork>
]]></sourcecode>
        </figure>
      </section>
      <section anchor="failure-cases">
        <name>Failure cases</name> Cases</name>
        <t>This subsection contains test vectors which that are not
compliant with this document. The various reasons for non-compliance
are explained with each example.</t>
        <figure>
          <name>Multiple instances Instances of the same Same SvcParamKey</name>
          <artwork><![CDATA[
          <sourcecode type="dns-rr"><![CDATA[
example.com.   SVCB   1 foo.example.com. (
                       key123=abc key123=def
                       )
]]></artwork>
]]></sourcecode>
        </figure>
        <figure>
          <name>Missing SvcParamValues that must be nonempty</name>
          <artwork><![CDATA[ That Must Be Non-Empty</name>
          <sourcecode type="dns-rr"><![CDATA[
example.com.   SVCB   1 foo.example.com. mandatory
example.com.   SVCB   1 foo.example.com. alpn
example.com.   SVCB   1 foo.example.com. port
example.com.   SVCB   1 foo.example.com. ipv4hint
example.com.   SVCB   1 foo.example.com. ipv6hint
]]></artwork>
]]></sourcecode>
        </figure>
        <figure>
          <name>The "no-default-alpn" SvcParamKey value must be empty</name>
          <artwork><![CDATA[ Value Must Be Empty</name>
          <sourcecode type="dns-rr"><![CDATA[
example.com.   SVCB   1 foo.example.com. no-default-alpn=abc
]]></artwork>
]]></sourcecode>
        </figure>
        <figure>
          <name>A mandatory Mandatory SvcParam is missing</name>
          <artwork><![CDATA[ Is Missing</name>
          <sourcecode type="dns-rr"><![CDATA[
example.com.   SVCB   1 foo.example.com. mandatory=key123
]]></artwork>
]]></sourcecode>
        </figure>
        <figure>
          <name>The "mandatory" SvcParamKey must not be included Must Not Be Included in the mandatory list</name>
          <artwork><![CDATA[ Mandatory List</name>
          <sourcecode type="dns-rr"><![CDATA[
example.com.   SVCB   1 foo.example.com. mandatory=mandatory
]]></artwork>
]]></sourcecode>
        </figure>
        <figure>
          <name>Multiple instances Instances of the same Same SvcParamKey in the mandatory list</name>
          <artwork><![CDATA[ Mandatory List</name>
          <sourcecode type="dns-rr"><![CDATA[
example.com.   SVCB   1 foo.example.com. (
                      mandatory=key123,key123 key123=abc
                      )
]]></artwork>
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="change-history">
      <name>Change history</name>
      <t>(This section to be removed by the RFC editor.)</t>
      <ul spacing="normal">
        <li>
          <t>draft-ietf-dnsop-svcb-https-12
          </t>
          <ul spacing="normal">
            <li>Split out Encrypted Client Hello (ECH) to a separate draft anchor="acknowledgments-and-related-proposals" numbered="false">
      <name>Acknowledgments and convert all remaining references to informative.</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-https-11
          </t>
          <ul spacing="normal">
            <li>
              <t>Narrow set of post-IESG clarifications:
              </t>
              <ul spacing="normal">
                <li>Clarify that that Related Proposals</name>
      <t>Over the fallback addition years, IETF participants have proposed a wide range of the
QNAME was for the AliasMode case</li>
                <li>Note that some implementations may not allow A/AAAA
records on names starting with an underscore</li>
              </ul>
            </li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-https-10
          </t>
          <ul spacing="normal">
            <li>Clarify rationale for two recommendations</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-https-09
          </t>
          <ul spacing="normal">
            <li>
              <t>Extensive adjustments based on IESG reviews, including:
              </t>
              <ul spacing="normal">
                <li>IANA registry changed to Expert Review policy</li>
                <li>Adjustments solutions to
the use of normative language</li>
                <li>Revised and expanded description of HSTS behavior</li>
                <li>Expanded discussion of CNAME handling</li>
                <li>Discussion of SvcParams in AliasMode records</li>
                <li>Restructured ABNF for comma-separated lists</li>
                <li>Additional references and many other minor clarifications</li>
              </ul>
            </li>
            <li>
              <t>Other changes include:
              </t>
              <ul spacing="normal">
                <li>New section on interaction with DNS64</li>
                <li>New text on "CNAME at the interpretation of wildcard owner names</li>
                <li>Adjusted guidance on default ALPN enforcement</li>
                <li>Removed mention of IPv4-mapped IPv6</li>
              </ul>
            </li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-https-08
          </t>
          <ul spacing="normal">
            <li>
              <t>Extensive structural zone apex" challenge, including
<xref target="I-D.bellis-dnsop-http-record"/>,
<xref target="I-D.ietf-dnsop-aname"/>, and editorial adjustments based on area reviews,
including:
              </t>
              <ul spacing="normal">
                <li>A new section on SVCB-compatible record types</li>
                <li>Reorganized description of client behavior</li>
                <li>Test vectors others.  The authors are now in titled figures</li>
                <li>Adjusted mapping summary</li>
                <li>Improve description of rules for resolver handling of invalid
SvcParamValues.</li>
              </ul>
            </li>
            <li>New text on cross-transport fallback (e.g. QUIC vs. TCP)</li>
            <li>Improved explanation of use with domain-oriented transport proxies</li>
            <li>HTTP terminology adjusted to match draft-ietf-httpbis-semantics</li>
            <li>Improved and corrected IANA instructions</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-https-07
          </t>
          <ul spacing="normal">
            <li>Editorial improvements following AD review.</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-https-06
          </t>
          <ul spacing="normal">
            <li>Add requirements grateful
for HTTPS origins that also use Alt-Svc</li>
            <li>Remove requirement for comma-escaping related to unusual ALPN values</li>
            <li>Allow resolvers to reject invalid SvcParamValues, with additional
guidance</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-https-05
          </t>
          <ul spacing="normal">
            <li>Specify interaction with EDNS Client Subnet and Additional section caching</li>
            <li>Rename "echconfig" their work to "ech"</li>
            <li>Add a suite of test vectors (both valid and invalid) and more examples</li>
            <li>Clarify requirements for resolvers' (non-)use of SvcParams</li>
            <li>Clarify guidance regarding default ALPN values</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-https-04
          </t>
          <ul spacing="normal">
            <li>Simplify elucidate the IANA instructions (pure First Come First Served)</li>
            <li>Recommend against publishing chains of &gt;8 aliases</li>
            <li>Clarify requirements for using SVCB with a transport proxy</li>
            <li>Adjust guidance for Port Prefix Naming</li>
            <li>Minor editorial updates</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-https-03
          </t>
          <ul spacing="normal">
            <li>Simplified escaping of comma-separated values</li>
            <li>Reorganized client requirements</li>
            <li>Added a warning about port filtering for cross-protocol attacks</li>
            <li>Clarified self-consistency rules for SvcParams</li>
            <li>Added a non-normative mapping summary table for HTTPS</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-https-02
          </t>
          <ul spacing="normal">
            <li>Added a Privacy Considerations section</li>
            <li>Adjusted resolution fallback description</li>
            <li>Clarified status of SvcParams in AliasMode</li>
            <li>Improved advice on zone structuring and use with Alt-Svc</li>
            <li>Improved examples, including a new Multi-CDN example</li>
            <li>Reorganized text on value-list parsing and SvcPriority</li>
            <li>Improved phrasing and other editorial improvements throughout</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-https-01
          </t>
          <ul spacing="normal">
            <li>Added a "mandatory" SvcParamKey</li>
            <li>Added the ability to indicate that a service does not exist</li>
            <li>Adjusted resolution problem and ALPN algorithms</li>
            <li>Major terminology revisions for "origin" and CamelCase names</li>
            <li>Revised ABNF</li>
            <li>Include allocated RR type numbers</li>
            <li>Various corrections, explanations, and recommendations</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-https-00
          </t>
          <ul spacing="normal">
            <li>Rename HTTPSSVC RR to HTTPS RR</li>
            <li>Rename "an SVCB" identify promising strategies to "a SVCB"</li>
            <li>Removed "design considerations and open issues" section and
address it, some other "to be removed" text</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-httpssvc-03
          </t>
          <ul spacing="normal">
            <li>Revised chain length limit requirements</li>
            <li>Revised IANA registry rules for SvcParamKeys</li>
            <li>Require HTTPS clients to implement SNI</li>
            <li>Update terminology for Encrypted ClientHello</li>
            <li>Clarifications: non-default ports, transport proxies, HSTS procedure, WebSocket behavior, wire format, IP hints, inner/outer ClientHello with ECH</li>
            <li>Various textual and ABNF corrections</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-httpssvc-02
          </t>
          <ul spacing="normal">
            <li>All changes to Alt-Svc have been removed</li>
            <li>Expanded and reorganized examples</li>
            <li>Priority zero is now the definition of AliasForm</li>
            <li>Repeated SvcParamKeys which are no longer allowed</li>
            <li>The "=" sign may be omitted reflected in a key=value pair if the value is also empty</li>
            <li>In the wire format, SvcParamKeys must be in sorted order</li>
            <li>New text regarding how to handle resolution timeouts</li>
            <li>Expanded description of recursive resolver behavior</li>
            <li>Much more precise description of the intended ALPN behavior</li>
            <li>Match the HSTS specification's language on HTTPS enforcement</li>
            <li>Removed 'esniconfig=""' mechanism and simplified ESNI connection logic</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-httpssvc-01
          </t>
          <ul spacing="normal">
            <li>Reduce the emphasis on conversion between HTTPSSVC and Alt-Svc</li>
            <li>Make the "untrusted channel" concept more precise.</li>
            <li>Make SvcFieldPriority = 0 the definition of AliasForm, instead of a requirement.</li>
          </ul>
        </li>
        <li>
          <t>draft-ietf-dnsop-svcb-httpssvc-00
          </t>
          <ul spacing="normal">
            <li>Document an optimization for optimistic pre-connection. (Chris Wood)</li>
            <li>Relax IP hint handling requirements. (Eric Rescorla)</li>
          </ul>
        </li>
        <li>
          <t>draft-nygren-dnsop-svcb-httpssvc-00
          </t>
          <ul spacing="normal">
            <li>Generalize this document.</t>
      <t>Thank you to an SVCB record, with special-case
handling for Alt-Svc <contact fullname="Ian Swett"/>, <contact fullname="Ralf Weber"/>, <contact fullname="Jon Reed"/>,
<contact fullname="Martin Thomson"/>, <contact fullname="Lucas Pardue"/>, <contact fullname="Ilari Liusvaara"/>,
<contact fullname="Tim Wicinski"/>, <contact fullname="Tommy Pauly"/>, <contact fullname="Chris Wood"/>, <contact fullname="David Benjamin"/>,
<contact fullname="Mark Andrews"/>, <contact fullname="Emily Stark"/>, <contact fullname="Eric Orth"/>, <contact fullname="Kyle Rose"/>,
<contact fullname="Craig Taylor"/>, <contact fullname="Dan McArdle"/>, <contact fullname="Brian Dickson"/>,
<contact fullname="Willem Toorop"/>, <contact fullname="Pieter Lexis"/>, <contact fullname="Puneet Sood"/>,
<contact fullname="Olivier Poitrey"/>, <contact fullname="Mashooq Muhaimen"/>,
<contact fullname="Tom Carpay"/>, and HTTPS separated out
to dedicated sections.</li>
            <li>Split out a separate HTTPSSVC record many others for
the HTTPS use-case.</li>
            <li>Remove the explicit SvcRecordType=0/1 their feedback
and instead
make the AliasForm vs ServiceForm be implicit.
This was based suggestions on feedback recommending against
subtyping RR type.</li>
            <li>Remove one optimization.</li>
          </ul>
        </li>
        <li>
          <t>draft-nygren-httpbis-httpssvc-03
          </t>
          <ul spacing="normal">
            <li>Change redirect type for HSTS-style behavior
from 302 to 307 to reduce ambiguities.</li>
          </ul>
        </li>
        <li>
          <t>draft-nygren-httpbis-httpssvc-02
          </t>
          <ul spacing="normal">
            <li>Remove the redundant length fields from the wire format.</li>
            <li>Define a SvcDomainName of "." for SvcRecordType=1
as being the HTTPSSVC RRNAME.</li>
            <li>Replace "hq" with "h3".</li>
          </ul>
        </li>
        <li>
          <t>draft-nygren-httpbis-httpssvc-01
          </t>
          <ul spacing="normal">
            <li>Fixes of record name.  Replace references to "HTTPSVC" with "HTTPSSVC".</li>
          </ul>
        </li>
        <li>
          <t>draft-nygren-httpbis-httpssvc-00
          </t>
          <ul spacing="normal">
            <li>Initial version</li>
          </ul>
        </li>
      </ul> this document.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9y9e3fbVpYn+v/5FLh0z4qUS9ISJfmhjKdbkeVEtx3bJSnJ
7SnXKoMkKKFNAiyAlMy43J/97uc5+wCgbaUyc2uNVlUskcB5n/3evz0YDNwq
X82z4+Qyq27zSZaM82KaF9dJWkyTZVqli2yVVUm9zCb5LJ+kq7wskts8TVY3
WfL81WWyg/+5/OX0e3rjx6urN5fJxUW969LxuMpujzu+S2Zlhe+6aTkpoIPj
ZFqls9Ugz1azwbSoy+Wgvp2MBzer1bIezNNVVq/cFP45Tj4+P7k6++RgHNl1
WW2Ok3o1dS5fVsfJqlrXq9He3tO9kUurLD1OfsiKrErn7q6s3l9X5Xp5jL2+
fpP8Ch/gHH/AD937bANPTI+T8wKmWmSrwXMcjnP1Cob913ReFtDzJqvdMj9O
/rwqJ/2kLqtVlc1q+G2zwF/+4ly6Xt2U1bFLBi6Bn7yoj5Pvh8nl5OYurVa/
0Yc83e+zIv64rK7TIv+NVhfGXZbX84y+yBZpPj9OcGX+bQx/1JMhDDDq4qdh
8n1e35RL08FP+fvMfgrtHycn71NoLbnKJjdFOS+vc5iR6WMxpuf/LbvN/rbO
ZuV6OM6ijs6GyavNdZUVpqOzKn9vP/2ajjJ45/+mGRX04hBecq4oqwXM/zY7
hv0sZuGvJHlxdnX64zE1IYe19yJbTW6Sl/ktbuMl7lNaTXv0CB+Un9JNMtob
7fFbaXWdreA1OlHHDx/O8PUhHurh3U26urvGMTzsucFgkKTjelWlE9j/q5u8
TuCMrhdZsdIrkNV09Ht4rHt0rnt0sHt0G6qsLtcVXKMqm8CZSnYuLnbdarPE
t8pklk7yeb6CAVIb87J8v14m5SzxE4bLVWTZNJvi44sUdnFSFkU2wW9qB5/B
7uNxTmq+rngA17ASKV8qHAnsQX4NGzZM+OrxSGqXzuflXZLqm9jBOEuWVXmb
Y3+zqlwki/V8lS/nWZLO8SrQDiRZMV2WebGq+y5Loa+7fIUd1uUkh5kYKlEn
OzoYWMGiXsIlwQ7gxpRzBxOZ5dfrima526elg3uaZB9WWVHn4zkNqV4v6bXZ
erWGL9c1nB3fKtxUnmdWTKrNcoWbjwt59fIyOZ3nsEs/ZjDLXZj61U22gVnU
pcuKdEwzytMaX4DlTpfZB9hYOI4FLODdTQ7Nw1YXJQy3rHksNMvTVyc/nQ3h
IGSeeuGDaXKbVjlvFzRHy4zDgtHye7QPHz/+X/jvs/PB8yGRNjx9cMkGNVyE
YpVP6k+fhu77jewBjm1RwpztYYAVwQlOaHKwXzN6YJWkq1W2WK7wVDmgjjBD
uLwwrnBa+vhirQexhnHOgI4vS1jsVZ7Ooa0im+XcwriEMS+zivot4GwQ8a/y
23SyGcI9eJ18f5ZcnP30+pez58dJfC3g93GGY4c9nqfjsqIzAUPPi+QHWIv1
GAZ77P6sV++aPhtOysVDpFJMpB4C1R/AmUO6/5edr350l7dmUdYrnCcO505I
+y0cR9keXEAdbj8pl0B887pe490BMjBMoNX1HM7iHBfFpbdApOjEwHtVxkcp
YdoOB/wa5zdbz+eb3SSdTLIlHBn4C7oHolmvalguJCKLfDoFEu4eIFOpyuma
9sTRcOm47PSU4X7PDLe322CScjNl72s+WLAWcD1XeEiASq2FLuDZw8HURGX8
Faexw/7YA8W3AT5bYPvZ1G3Z9mQM1+e25GNJt5lOoKFG0tV6XMJFXACbnWaz
FOgH9Z5VfSBV1+UKbwlKE9BuBgewQnohFKEv/enhr7J5dgsXwy3XcJwndNth
OV/gff+Q4rz7fLF0RSZraK9YzTdEdudAqsoC/jjBdh/CWyfw488/TNLhSWDq
mNzAmUEW1k/mWVoVRBjwZbwR52+SdDqFNoH4wBqeA8EobM/8Su3otsKRX68S
07JcUl2p4rqPF3YB/GiMTzOZWy/hIMHmEkfqJT9fvCTqzgyq15dtok4fHkDL
yRlTPFg+Q+iAxPzr2emPgcKs5vUgq4v806e+g5dqODNA2nCjCgcHn2kvHPSN
bAd1ovQdp0r3+Sa/voFHplmdVzrgRV7ki/w3uhWuWC/GQEzgboEAVUwHqypf
1rSbzNJqug55RWzM0WrBe0g4p9Och2AP5dDci/gOIAFPbrL5Eoh0VvAq0zRK
6t2fdHcHtIF57BRO0TVyWDNf3Ay4hXP8HoQ5XE/auxKveGAE2fB66OR9ZS2y
qV5ykJOIRKkXXTbnB6brCXQv6QGVGuo7wLt7sMi/3uREXWA9JilQ6AmcrroE
DpovgNnBIbmBRZjD2uEVZBaExBxam5YZc6kJXN2KKBawnAG2ggeVHiX+hHwv
L+CA/W2NS+EXT3m/HysKG7RsSm3SZIxb6pCa80XHhYb1q/N6JRQgsHHL+1c3
cBiub1QxCFxbRZZ5yepDv0EB4J7japsDsTtsCl+zvAIaDydyUuVjEcHovABD
TpEhX7OsP1iuK2DhmRfEnAhitH640ngJl0u4Q9NkCid0guQDR5HNQL3JmZzQ
vt7hcgDhu4atnXl5K9n5+BGVk0+fdvm+0BGNB1atkcIiUQaSmDNtwZPmcMQD
JOEwS7xXMHiWDaVR8x20D6IdCK50Eon2r1QKcfIevkbnkh5mMUb2MRB4P7EJ
zxP27zYr8G+8NSqrRNQe+sFzQTOAFTtZrSq4w7ME2GI2R7FGP3l28eL0ydHR
6NMnp0NBmorjsXcahnuDMuEdkJESxnac7O8mvRMUyH6Cv3s69hrGTHSHb3Bt
r7DTK0yD8tv7XTKCpoSVRo2hHosnGwR/XPr42FqOyA3qzfDE0JlGw6oaAgbH
9tltOl9n5hLQigK5IDn5AnTVE2gY2nIPHoBWB0dF5RFZF16ka/im8QXeYjyF
JLMrv4MPlNHBgGGrQMIwA0L9A98s8PACu8EjD8rUt8kbP/ouqZ6vBkriLOSg
foIP4LoYmtEHTQpVYTmM5uIbVYC+osnzdGrTzxBG8lwJGLwDF1u6BjLWPbKb
9JY1pRr6ssuMiibc5mU6Rn0qR1EOdxG1iVvSRPnkMA31DaDku9p4qYjuCOga
KYqFcD5x/ZTCQhOeIhYbXk4QxfPMn6igK11cXGarOqwXdoXXYIiqqxVe8lly
d3c3NCyElQmm26Sg8Iow3yateQzEMwPqTWwL17TKsuT0+asaJ4xCDN7YrLjN
q7JASskKIYqCuJQgk1asffPooG0cGUkjVQYaVuHlIyaQJUhUoLcVpH9Oc9QZ
kPzaDnAfz0SKpJEP5mhtmK2LCR9EWGNkfWnyGw6adC3lBTCQnuWguzSuJVK5
Sb5krqvMoWbuIIR9voF3VXhVHs3MyTJ6PcIbJV7Cv+VeovCS0EaTTOSPnW6Y
OwnX6Zruqxq+8AUjl+ACCTkOLBiu3mS+nmZ06U5Z/gtMRhoAcW7nTz+fnwYV
eZduVtf5B/EOXzkIAh5IVRPSI4HkfptcirJclMVApe+r0zc0vJ+fv0nwy9pv
V3J58Qvvldf9dlDkEXXYryldBtxq+B1uEAi4t9muNy8gHbhDzQibwxHCP8gH
Ro+fAB8gQo8XfIyHFlkostdpiZJroEQkT19eXfJoUP8RwyJOGD7H9h49fvoY
2qvzazxSxJZSlrNFSIZx1HBJ4DSLAjcmc8GUVKMsneLREPGazgJQGdou1dRY
t0ZxF9VHUkVwLXfqDM8IsDN4hhiZXz/SxJF9bkhbgva3SeUglMPYyVwRqCMu
HJlOis7tZi7x+hbJbXbXwShgqKBt1SKVjeFiz1hK75CJqCOY9l0Ksg+J+sjw
SdnHx1CBBboEklKut4ioNsofsOmkC+yctE5BX6T4+dyxDFUnKGHO+XSvrJVE
OPoN0OTaGQo8KaekEjH/5SuO+sYAdD8QLrxpZLj7WQHCCw8oAxHlHOA3RhCi
D5Hn0dV2dN9Z3me1Dzu2LB5FMP6z2ZJn/kH5dVaAIIE50gWCCsC6Bazmm3k6
wVNMphZ8t2ZGLWxcJTpi+LXh+I5MlSxWin4cSS98oqQZovcbL01+QRbzOtos
z+ZTJmrEZpZCAelzMYDoMxVSt/1hcnk7eVPlTGqhv2UFOufuMT261M/pCOe1
t4XCBPjIoxqGW1EjMeEpwLRha0ieqoOtAGXsE/4UW9tTWgHP+BMwdKNhckUW
3ldkk74iew+uOzM7PNw57TyuorBZej7ZQasADME3tpuU+lj7htLj9tDAyh7w
UqBoAuRUlw5W4iSZg8aEnVtBMSfhRS+tStudnaUohJiJQetooBASF51d2jmc
IajBQE+vi5LWDt9/LuSB3sF9ApmsWNHZQeujOy2FfcJQ2IA9WVckO4ioWaHl
CaiF2ImYBME5K1ayr44eXNNp5AWCc9ZPTviKWRsMW7hE7oDhLhJhyYbrXgal
k888SiM1XU8/tME4A8kQDhkrYadyWWST13V4rXbCkqfSlRXglZLygIKs2F4C
tKXo/IECgHCVwjXbNs8kLAhpdnyZG4NGDTmWt9lsVpOSmq5WSI7zYjBOQcK9
yyfvQ3fYFXdK4pdTCU5m2LGYrDjwioi+Q8TAk4toJNFInTuPzlqf2Yw/8g02
FYRma9efpquUKPdctGJ/+s3Jd1+lkXga2zfaiPtqbaRbzoIVQF7N832hfhQv
1/Vj1ma0bi+RLlBLkLXw0hX8fTJfDWCxHAg28Cv8hqLN4ycHT0B+w+Gh7fAu
zen68fSINbOx0bMb2Np8Jf6GHa93kO2NTG+7ToyOwZbJQwlGVzPxvsOzo73r
ec7JjHqbqbBFwlT1Dd4g2Ee8QbBtME7vl0CBijSqnDTL0lsO2NoD0vwNrCbK
NFdZtcjJE7hx7vUaCGz4gPwHac0uAxawFgv4lSxjLGf68yXXC94gIgjMUYze
wR6QwOGDMc1yNZ/9fHEOzaBF6J3XDd4xNyOrIFr+4DG8jmoSJv8V9PkOP3g3
RGEeWUpPDl6PdPOb2E/T2Ts1YnqFZQeS/I6l1ne6RzDCPuuyc+JVwSAeTPpC
CqmTIWuVQQqGBuSIhiEGRa4WVafHmlAPZWwUrw+PDpEBxHMjhuknyAtAYrEh
yX5C/uWgdOmV8k34r76pk7C+6PljaVssyWj4yUlCVn2dJfvSRx4ECg7TxZ5P
YEpdt7nHOnWw75t++oFTxnK59aY0fG4l+grumIQiKUkLelo1AHW1RKojKZj2
jNMVqsXlGoypbICDDYEX8JKQPe3w6VPizHTkaS5k+ko9X/SbJaEaPRHRhAb3
PaXiiy6eVG9rZAsDCub0xje1yOK1cOdrGBtwBfjeG4FvUYt7X5R3Bd6NbVZM
GYYdrXjJ1SQt15YVEq9/1RtYjAWbceGqzjORV4EkozsP1q3308+XV70+/5u8
ek2/X5yBGn1x9hx/v/zx5OVL/4uTJy5/fP3zy+fht/Dm6euffjp79Zxfhk+T
6CPX++nkP3p8WHqv31ydv3518rLH588apXEJeUtxgysgtsh10tpNrdD1PSjk
+4doNkUteX8fdlf+eLL/GO4gWeflZKKAx3/CCdygkgUEnRQFILZAI4ATkl2k
Rp0XdoM8lA6pbDgBavBGdeLjA7JVG/l/W5CCGJRVD3l0uOsCnWXT/TbuGbFl
2bt0fo3X/mZB37IcRaEaJiKB6UC4huJz81/ndXz5OyQp6O013ebmmWxOkQ6o
I9EK7fWwZWSap+0aSMQFav5JlyEeDf2FWKnW87Si3XFBHvCLdrQblEUaOtAC
cubA1J3aB4mzqW2i7mm4Bm7qNBbWRcpQWkCGpzhgglic6hleKPMqcCUqh5Ic
DX9w+ui/ZxuhxvrJL6ioDJMzJHX2qRu6nlZ9SAItd0w1MhQ0mNIOk19YlUsp
oAHlGiIykT3NSpLQBywzdusHJ32GMxD1Lu3tqD5ExsZZDsIYqRlAWqtgb3Bk
6OpbtRBWCegnyvEonZL9GIaeVTA01kJh26+Iy+cUL2EGWjux/+VVoJ1VOFK0
eSxQslHnf+rYOqfw8UGklfEF6nrw3X8nl8L/eBe0I76/TE729w6O+l7mPxru
o4AKa8gWH2gCNHeMhrKqu1Ev/fEx1CJIXDo3HwiIRh+2qlL7GjuX7PTOX/V2
QSmDm909soPhaHjIsrYdCrE6lQeY1ZP3LdkbPDo6ggacGSw9/O6/836SoQNW
5TPr0NctM6oLKRh4VVYgKaWTbFBnqEcgDccr1Tf6g77kGhfJnopn0RWii5cw
ZaTwNIwijE67vYQ8GFCt/xNNxnA1zk9enXivNdtzSMdR9szL17qlxP4SYRtw
YigypkRRRVbUz36Iel3HIesnrWGRaYY0ISCeS6Bnck1gHLAO0BL2TFdKJepk
f/DoIJmAjAFyACplFFzmdxQYetob9H5D5rsHvzxVXjvo0bBOvn/1Qljk0ejg
EIMZ6OBS74P5JKGfZ8l/+/Bof/D4BH7/Dr4c/OZPty4HPrT/7aODHf/mw+T5
+Q/nV/AvdLYbvaCt2gb+3HvWi0njX6J3eKuf0VQHvB4wlkvgIyewByCdfUhO
6AW2/+jPs+Tb16dXZ1fwLLcg6hvQjIEnkLDfaNWT2xh1CKcfv4WDuq5FW3N+
tXUc04xpn+HFcJD0U7JvLikyieNz3tEQ33FElfwhUnyBw8+ndDO8C7laEaWD
s4qUdiAkikg9KMNFVjlL6ukWvcdT734NkRwiLuMikzk2miQevXKRr6Af1m7C
oFwsbyUYCodNn1TjHGRPoOlkehd3f5XJObfrlawLEmgHKGV23APXgy9e4U9P
1FD6Q/UauQPOmyZXIrCSIKC6NajjtAO/ZVUJ9+QknDWVJcmkxLd2nOmmplbw
EcM7sjQKZMP9g491Mfy7a3kzp1CxKlOmoSxQLBsYaBJd8Xhtm3qjCBcVurFh
mg5o5QIF/TftFWNBkBx9tPoic6M5LiWtPm0QWIwZoG4H+FdgCEyd807ylIBk
nhixGK0u1RQ1uzGsN/WrOgIG88HWZ9gfs2F2yJvF4bvFH6t4plZyofRoxSF/
XpqMBiXcr5UYD8jSadgXyioFKQLXzMDEEEI6LYYj4TBRceXDhwImRZjB4aZw
wgE6UnjLA5/rR4eX/KcoaaP5ldXPeVZcr24GaOfJP+C6YogGyZIkhASWu49P
K3dkxT/iB32a8Hqh16PCYO1iylFeQdaAAeyA/FwvgP+TQR3mTNw5obWplT5g
CHVubKq0xjh6+BpVkAXanIC31/lvKGkZqtCSZjkytxjQJadYOmO3qcm/jSfz
85y4bq5k555Kw7oGkZSMUyNLQXOD7fbC6lySEpGnRTpgEdCfLBWhWLwc7n55
ALy73sZqZ4VrGZ04DRTYozXmPekeJPZb8H4JD/eeGumQDWY4GDKsp2qEi5kQ
XD8OLMB7Oc3Y4BG2PJJ1YmEnElNynMOkyjg6W4ULGapT4z7darqTeCZh/HBF
4RBi78iH+I5it1kx1QXji11O0JyvEQBBZMN1aMk66LqGp3BZyGm/fWTfdiyJ
xBzYc+ND9nwsS/YBaPuKw6tg5WCOr8pVFtzbNVw0vkRsTxLjWO2fqDIZajJd
wzeomUfLizb7GZFG1Rj9QvWtZYuWtMpY5Lzh8JhKwlmI38woJDqdvEdWgFeQ
aKMxS/vIczSHiLHXOBZYJmQbhDgj5aLT9/6aqd0q+E9zySCYp17KSJM/UZjM
mNg1CVcgHJkAJdZHxR/KoWoaWSAdsVGxn3hqqe74NRK6Guhb1kdvFhrYKSAR
GrKORIpW6P1VAli4tWG6zG1Ez7An8UWg77Mvl3wyGkIH7VCMC8bvV0ih9RsQ
coE3W9snbQ/xMK9bw42pyiVmHmSifbGiIJYLMmwOasmGEXfGGwmngUOwXJJc
KOarmngpCxob6xcLq9HkK05zRmj9s6mYonnAalnUBiWcwjKh0fAAYyn/9eeL
czR1Hjx98ojkUFSN8JqVHGfBORj5XLRCik6lHsXszi5gjtfQWOQctTEbBxOZ
l41AhQG4GVlnmeSpMcn13uAbb2jGySvaJ9FLUITJV6pC6fZrwCuHfxu7IFI7
2g8bEOm5gDcbacfK/FJ2nEs0mPhRVQMnUwhFNLDfw37Zl3DDiyAMepcm7SXJ
hGguhP+H+AcUERy8zkYQ7hWOF4WOwTEJyvShVd0fDUdsEXtBjjzgVmiQxJgZ
FRIWsAbTlE3pcHbTSpQQDsfAZdDohk7faN+pI1QiMuBI269pR9DYQw/gLwO2
3a8rDXYI9LTwYXPo/OOwCzJisgLCsWFItKOwMdF2MM5DwomBpkaRfJhwNGlw
JqAZa7IHq7LET4GixImTWe1NgNwxuaAD6UL9pWbHqfRCj9KWYQiDiRqcULwT
pUnUNzbGQiw8f31yeHgw/OusLFvkKXk82ttLzl/xAdpLgDYf2gB1GAVMQe8Y
r2IPGjp++LDR1DF2IrZ9PZgU734YB7yTjN2aBnzVpxsF57T/xQm1RpnwPPxE
Djoe2XGqb4P6XzzrjdOqR2ThWe/J3t5hL9ntmCufFB/tTWYZPITkn7Q0BZvo
Owlz4ji8WnyuQnC5QzyueP+MXzokx8ENVMKrBlGlX+0MOjqbshewrG4HOD6c
QBwwD1St9RwAQsobHP8xUNb3uNQod//WaYl0akz9+HGL/QzDsR48YCsf6t38
Gnz0IFKC0JSZK5NvGPf2uhy5MKztoVxDNu5jUAvJ/fz854O2kJp6SY8FCxBn
+pj9SOKQaKVxZDGHEXGeD4s/RsXQwZqR9lUjypdBkuJVdyh32SE2ojM4HFxC
htmajzJcjsLmuiDZMpsmIfuiVrEgspWytmAcNBjJXGcc8ApNcDqTLgCZHlRl
i3bFR1N56VPkHb6vnpxTR6olaEoF5aDYqeL6evmrum50RmqPMjvM1uPk3eaS
UxqkhjhE7iJNgnC1mqujpvueIsseY4giyiFwkWBWSX2zns0ksZN0Fx+nxqGH
3s3OvYlJzhuMFn2yY4GOjJ8WOV4ZNy/T6WCcztNiwiYWuhHhRH98YA40hdI0
zpC9DiFi0aTopsbqrRm9cnpkmuQ0pPPswwCbyS/27HJCW0j0rTwpCAtILjsJ
gnIhDkw6XGI0EoV2r2Rth+qzyBcoS2gODsW/6FLYhAafiyuHDqmSwyjkvtja
fCYT5QrgO+qfo4BlDmHYf7o/CnRKfQrtNTZuA4xkwwwrMuFJbKCX8ekOyGxp
sBRx5Xy4FaUU6vkIqn7LXyjhxiHdeKvDfNf9XJBSIUleYbX0FE5LXoLZTLU0
E22Hse/k/by44BxzSaqmc0/HgoNS1Q7rI6eoyUIVPqPiyEaGcVj/kPeho4RJ
cb9O7kxDriT+fUcsnbUpVqXmZbls7o+nobUloqS8BgOQDweTgzp06FAbMBtD
k2nFuky2wMzo5E5ioHKi5801JVHauEGuONKpYXJqv0d2qJBxiksoBh22PaZO
Ai1iqAyWbMhlO+1ok+QPilC0Y4qFTbaVh6xHlgAiSWzvyR735Dh21Ma4p42s
P7l30EojN9Ghas0iGDzjRUlom0XJSIw8eBSJke3WYBY/0wUIk8ZjFgx3ZAoO
+YUgKCPIhJV5XbtVjo6cTplELYAFRRyoxS9AOXMc58xejmDfppT1G3IwIl23
c0uCApF3DgIkskVeZ0LR7tJN7WXXhmZGV8GvgNLj4JiYp5Mo0VMpIrE4e61Y
0ORLhSRjvnGS4WcT91GHsBQ3kygEjhuerVmG3JqGKEmmlAAl0eGxeURMJwF0
ItJosZFhnPPkmoe3I49Wpf8tJzerHJoVGlsQnVWrMVieQpktcpA7Ty8Pfa/Z
essmZ/b0m9rsC5Ed4SewqWWBjnFOOCDOwnuqh0Fd0Iaomve9ipRGcb1DH9/M
4Vnt8GwinGxt4jfJ/k94KnMk6CWndsI2UqZCJpIGnn5Ke558TfsqYLp5jlRW
gjVX5Qrn69PBOYVb5BgMYeLYcRkcIXegqSLwMCf7rUl53Lpx4ZDvDKT/IZws
NIRmC1VaarWQaVK9WNzwAMyzlBzfWYvkSpAabDbwU+O9074dWcFnKxGqbX+w
lv+T7A4iKPD94E4jqbVN5oULFPAvalBOLx/buCj3yMAwMDoF2wMwKWuyMSAQ
sJzIe9B5SUACdWZPf7+Vji7vMM3gvF6KwCM/PVp4ycBL4esUx27wYsriGs3t
3H5E1tI5ktbrG2bsJmSX7rskV9jQcLmbi/z6ZiVQJOMMbaB24t7LWbHsfadp
XQaswNqP/P54EhDxXsfLE9FEj4aC0hELSvCUpEmGFE6VmJSoxQw5ovF471lK
pbySUrEiLnWxENkoIRUVb1M6FK3ZcK2PDyIltjvk3hAN6yv3jg1/sUzYm/NG
h21JZ80sX1ay0F5hkp1CdL3GnHiThNiq6UYgVg+vDF1Mlo7IrNmwQOPTDvVe
kgUwurYRlCP5+bTXBnCEDhTyAra8o/CM8YLBVx5yYNgH5Zpd92OrXYe06Wk+
um4cbiwu5XWR/4YH6dJ6z2slikIK2KiOAg2HJFppktxRF5jN5GKNmaRK1Myn
GNc7nw1CdHAPJVjcCrM6GAZaUpY85T1wcgN2900dDcOkxVg3DzuFxL/nJzZ1
8frjrBtjYeaF3GqLwwjpaukIquM3TiJT8sPMh+Eu1KfVp4dYgm9SddYzXIbR
9ZOsMZAJeWLvsvmcXfqXjShLCqwcUqyuuTAfH0zL1Sdyi5lPb0R+YS6Ab+1Y
H7Hsmo2lQCO8Q4Y0EEcpuUUQqEGGwcgPRFeGW2wBPBKkJ+ErtdMgaTED9HNp
WWmUyKuG7DGL0CivHsfsQx4Yq0myJRyW27xG/Dyn98HzJk9LzRu473JXck6V
FfwppHdyQ306y8ooVDCvNr3j2bfEdpp//vkd6nM4El5tI4Q18gxVLNCIGDqq
pEAj5TPmFDwPJoySw02BW04nmDVrOpCj4I2nDfufY78Ls+KQfPYNhraTfRbv
mG3vs4OKeY10HaQM+YYs7aPI0u7y7c12CcH0483oW0Vhsb9vM7+ziNscjH8t
/rTZ3X4yZIv8k7290ZZXDvANfOWEBrz/dDTcG46GX34cRZoE+ts/no6fHB+P
OE7+VKHU2KUE17Lpg3KuJ/xdpVSfziL+MXJkUDxAcC6rNXGgNlwfIO+aeWu1
Cj0hWILHECD7vI0nN2IOH2fxK3Ma7kuQs/5FHONZxMjpoC3n69p6jdX17UUd
XETh4Tb83WQOj4bJOcqjcc4gvs79wiMHQ8HIalC0YOb3/sjwXrKTzlD+Cyeb
dRcckVdfkLSGGaJIDqTKpsSqjo8vBQ+2znJXMamWPowBmMgyGVHesQm3JVVI
o19ID6jDqxjawjbGm2xdYfTvpFaYgJCUMAMSHFyQh7QkFmuqFxTuHvotFuil
BwaJobydDgPkxLpuNN6V4PkJi6Ld7szIgP6PhonxnTQPFVI6HG9mlFKfrUxp
PiG7I6cd0QhL4iV0C6ZrMh0Kr6kyMjmSgBF0SONZ5SGiC4p1etTXjCTTIb4T
wAmZtaHN9A59XXL1hK2caCCLEaHItKGBpSJAkblFuFTS5lKuY/ElHplag6nl
KUpjXro0whXBl1TZgHgtBqR49BLB1kA6tyuOeX+Rk2iYgRbtZB8IUTCtUfJs
ZL2EA4YrQ5BeoC74ZMMu6yNF1sV9NXwkpGpSrGWKICvZnEMqSYDFzVLNiCQP
0t7QfC4JM7F8HkcD4dJ3+PvSMXsacnFURdBy02yebpxa4jngHJG5AvoGQQ0K
Tm6dTPN6sq5rXafoS84NQm266/CjvZHSwsnhQLMV1By0kWEqSLnqOzQgf86W
kNyltbIEvKPbVlqD3RglwjILvnVp4XOfG5k6xPopUsCbKpgWsgTiwxb8+yBz
tPIdi9LYlpNkh+6w75CsA4h7yRIdHibWvtE2QIgVnwkAIzQOFTHZN8ZnZcta
UGcEaysSYpeBnrWTWAx03aCOaHgvysjsq8AhQhtoe7Kph8/cclpDXLjYvaZK
EENaurn2cnswTxLBS7Jq4HfUUOSaYes4kcR5Wwvl091te8f0omBfapyh6ft0
/6C5zzme0IYNq7Y2uSlxMTU4FP2YMlc4dCQYpBS/wNbcH+GTTXK2ycYw1poA
bPET/eCXESWoHuxRALFKz4EIR3ve11BgQcH0S0yWNuY1FukLxCThSKbRgsx5
HuqWTs32cyj6uUf1apALStH6LMkglBhSV40wgTGIqHfmBaneKUgAHK3hY6dw
fx6eKPYlK6Y/qkJqKI9S8CBzeppOqym5mYLTgMMldKHyukqXN5JyhfyFt5v5
C68qvHl5dgojchhzBPv2vLxipIGjJ58+0d8/cnLxk0MfRNUkjDiY2k05iAnt
RWtUtlbKjrOqKoGiXJ5d/PLi5PylH2nfhKrIMwi1mi8y4LPRbqpffoxO44Kj
YoIeyenVRoTtM5hb/tljBtfFCDo4alZ9CEHjPZla0Yi4QOWWXL13BSOv8gPI
OadZ4WNREfOgkXdv/XInYfo0VRItKMBY+Z04U/Na9mSAAFZ6qttOdfOgRp2h
lUqFMp0Foyz7O9zVkH9li8BFSDqNnSKwG94onInzM2mvY9S97IV22XYaoNTI
dIlzx6eggCx9/q8KFZwZzMe9H6FA5BVlBuBBYlmkHOMsODqUY2frFgUSi5Eu
qAnjw1bhhjLn8B3meiKdGILV72ZeXJbzfLLRYID2YdPVYefrNJtlYqGR7uS6
EkwUaU3XJgtabzq73QgnjnQymY+iJMV4xFsoBaHCbqcWxvAJXGEFd41ZdAd5
Ih0zRb8OyUEF/d5F7teFggN7VOpmk0JMyJ5sVCx2IrWD0aOA80jA8ayCA1dn
bAKiMMpvIt8ErOPUWL+IFis/FcaHKHQfNiG1QD+WZFJolXXtKALvw4bDvwmZ
5fT1q1dnp1dOYmQfjw72QyDK4fBgiGHNFML7+vTfL498LO3T0RPOyb0N4izx
EkeMLV3EKCs1ycns+SVp2KyX17zElEBxZyeJCkjWo2FxWwTrmIOA4u1UhNRs
6pTT4oCcHZCGd/GCxJjECv1jrAQeoXPDCdiJYgTj1ZnN4BuKh1RMAqQcu9Gp
YA8Qr1fpp9o8ZZpWNt/01c+FfH5eeqEumgNyN2MrwLR+voRF8p/reqWGng+g
7+oR0XS9GEVW+VnFecpq5uHBNO+CC1ozL2JklWHMdfwko+HoBuV1szDBNjWD
fS55zUiPjRViSz2ujzJ+VWtd9D4RBt6AaKYULE5ksUUIaP/xtHj47q5z3JYC
2O7DCRySsdAatuhWfZFxfR4HhTLWhKykMYBO7xJFbdSJCW/w4MkNtsV7jHjc
WWEEVaf0IPJ4RsukRz2oZw3vHFENpmGOuvEBHBZKjY0lAsJ3EmDEgiBJepWc
L9JTUHmtQSyqTAUHgRtF0TQT3FY8BcposHDKgJGqfT5K4DBqtDaJgPksRAR6
IAmu7sIAdKlfVRNcFoUpXtkWEW1WqshwpFNU4OKGclRvUoKntF5wwSadL4vd
uB5FezomXtLDvxP7CHU+hs1FCjBL/iz4fKDAcLsWT4hfKafSS0bnb24PaaTw
y6PAsa2pVY1fIGGWnBeh3NFeNz9Fq1Gbrjl4ltGopQ8vPGFjIfM0Sa6zMuCu
Ix0J2/9NbTpiGLNZWpNNVlVVHDoCyrZ5QAgg1THwCZkFMWqWLnL2gxGFv+Sp
fx8M783sDmLWJ52geB8fbIGo8/HEIMHJelpDdX+rPOyVeLaxughYL4oj246r
x/l+FkUDwTYkWNE4jQK7JRcSWjqNViBnQrkJY/fzTWGAVrakFgTPy3NA8TZG
9FtFxV5aQ3YCduhzk7KJJiWxzVECXDBLuiME6OODDvBFWvqV4mp2KgFst/WR
QWJYo+fZwO9n4ThpmDG4vJ9lh+J+JFVfozEsh+D8JhavDo4QMXjXMWL0ShBx
T4oakUUV7LGBKzl0XdMN+IPR8DV3AJ3cERV12QdoRYhO4PPdmEVyf9DouV5Q
ED3i6aqVYUw5p2W1LDVU0yTmcQifJZ+UGrmKITS3TLXlOzr3/Xi/JVxqb2E3
yxzOb3uXv6GLjzRm3uFGSXaYg0j5k4Ao7hFBlBbx8wxYkySMH00mAbomlFsM
AxWHFKe3hgmyxS4Gl+INMLHGYgsLKWELchtpEHtfAuDY5rYVxJTuDFDZGJx1
yP7VgQ6tNRQdZD+5Lr0fat+/ZhNdtm/LiR2Nbk5fcAWp0JlZp4MhTH7+5RUy
7g/Y5wu1OfqusGmrTpCZJoKlrbwt0vrMrScf2wBq0Bv2duMJpmGEOEmxfJhZ
nIvk7W9VP+nJdHrJIkuL2s4Qw2C8Wa5hJDEiJbfDiqRJeUyNc5NIAEe2OAmg
IJJcG4clOaZ8sGO6ikYiuouMBhihhieyXCMR/8/JsUkIgPAL4Z4/eiwZlmdo
oiErSVqADEM54JiyOdY0GUMadE/J5pv6oEClo0gkdFEpXN35EEu8ByDIoDih
L5pJkJRDAGFqHQiUUziJTdlijmhIUTrLrtepXpuO6FJn4yzZG7TKSYBD32vt
e8kLNTIMdATSna/YFlt7NSjEb7gEogD3fHToHP1jSH6I1LCGmbKtTXNSO203
isNOXJQ+cNJmPB8N94ePFXjj0f7hY95Y0r+YtfBoWik2DYOUDg6IZHkNsvYd
izwKqke3tOkWMDeUKBYe31p0ucAsgMVekkccT9YWiOXgTUA4nqYsFDJi2ovq
D1n2YVWly3KuNI1WtTkrsfmcv3E3uVe6rR5hcLAQWmOQL+lBXtSf0Bfq7bgg
wdN3TmJIKQeybReMQF80fhzBcektAoPgIPuoTJovp0TYPEmc9NyI2JDaL1zE
IgrRc52iRyOmWeoNdCTCrYuO+D0G9NHtCtq8ROqFpWxguurUa1Cj07+txfSu
Nu0ICETtAAia7r1WaFnoyhjjgEHShlPxIHhnk7eke6cLS+JE2fyMGFhDtXrp
PNaf7CH5phFEwJG7TDo+iBOVcx3Yy5hHCa0Sn8xSilO9rhmg6OMSwiVg57vT
TDWBsYcHvJ8GQXrxzR4qtMgFAwWUO8/ykjmcSHt9aKvH1KHwDtF5fCILaT3M
vHiplFnh2sixf/3vyThfqS3yYDQ6omx78T4oAHEg0RTmt1V5onOK2wAadbFx
gkCAeZxtdUkFUm+IIaImHVNRgGzqw85D/C1fQmI/dOOsxq7MWUBwRMjnpYYv
zn/oJ6+g9b7D/x5gGMSJPTKWRB8GbKTR/pN9BOLo/VwY5xcMDjNbReueEpLg
hARTlmKHwyFTgzBjAjzXaeP3UqKEK6Po20By+TL4ck124mjlibAcaKo4T0mO
0QHxxlMm20YF7eilzqJ7kmlpzJDD3jZtSAPyWbqY3ARF04vx7e2msDeCzkA3
ynI9Z32m41wYn4z3W1MvJKNjM1IEiJub8SopPnzYJdCd+FAx0T3D8yrhfpfr
MYFTnp1e7oI2i9ovhwl0PCSWRHy2L6rl4yePCU1TrEBdpG7FBTWyehX5a4Iu
Wa/zlU9hSA2crKhADl4jQ1+jcC9tqQIrRk3voKNxefstcrpA23ep9KO4k9a1
Py41zW7QYbCjFPMu2UyDhMQa4a8urIyuUl7EPj1GHhPvl3y4/fY9HhpkMl5k
uH0nHEQWDtjbP3eruG//EqUKrfJM6rCIBQyxeHzPwKOc0pEg8XvtmPnBn67+
482ZdzIHI3K/LaMxd03NWLdTvpRqmaFx+fL1zxenZ8mbi7MX5//v4OXZqx+u
fqQcJ7Y7nb5+0/zSogE66SJsAM6w02JGC0MCG9EYP8Zweyi7ITqVa86cwDnV
q/W4aRHBUMzO8a9KiorXQCAycncrE970LWrUYL20fAud0ELWxBmCYjBoHljQ
BGft45fIhrbI8fqICLAmQDk4SxyRTDE3uE6NkA89acFh93g4QowLDBzqXkoW
9nEpT9oaFyWkSopDxizfG3Moma85UfIDqwrJ7zDmFY6O0iKMrMkIwskbI33G
as7HB3EMC4ePS0ne2J5OtjS1O5ngGdhWGBzGAex6P4e/+l41S+WrAaWEIdUk
Go0sQ9Wl7eefsXKt11tvEWZ3URIsHm2m+hJ/JmNXRTteRqIqv/rAUdVWfNCR
vmlElr44dmgY3muJucS+QKlsW0hq8MvDeZQdGbcsmqjLCGOTTO9tmtpeYArA
xAu+luJIcaSb0lUbomlwiWEuTgzd3gVAMN3TnIKEfNigNdhwoHf7qJGYREHZ
aQPXg+S6IAI1owk2HOJMLtRQQcqZMQfOTrl8WNLqpNu05h0LxqgupdHooGP4
NYXcmi2ykWYkTwDpERA8ZZfGDFpV5DyRY8YKjs0Kj85p30ZkUB4Ml2LJomLr
ISjBur+9EPbqNSIRNg0vGF5AiAXFpu0Sm2juI8UGGlRFOzi3BtlnTjk5PKlG
9rUGBUcwh75lxaOkeM2AioURZKaaXcBgdO18S0t79EZjORvayaM9oDbzec6A
hrrgzhe1Lbftp6ZI0HCu16APMYK1+/ixEY9I5PGkGWRsqhWLl9JWbou81yxq
axQa6qigoMOlyaJa5xJtnb7nOEaKGpckYM4pPp/F/uLOUfiYKjLHDICUXOPJ
dKaf0zgmRq+LmCONgQIHcapwv6GBRqIq4VLFcSPedxiSevl6i1Qq4esuZHTi
eSCon6vTNwoKsT86OBz+dZxWDVAIgwmxj7k5+9sQuUBsfYRi67OQn7PPmUDY
dLLrH/zMD3Uz6kgB+mw3o6ibRjDDjWKq+t0h96fZIeAN7/5sWvvLMbb0ru9y
3S+KN+Ytp6XzFzocb4prlAxqMpuTFy2A9eBnvCs4II4w9jHjHIFhkO3aVv1m
hRkyVHedPTsqHwkSTWFrxHSjXIXrrs7hbV/syyoUgTuYc4259eODLiuvWDti
manhZOuyW263SHlTeKOpLK2kGDgDo2ekH7AlViTA2hGAtpZCCphujMlkagtr
eZpgLWx7xxzxVDYGbClwJ46iXQaZYfuUljAxurvzvSzSDyTgeX5HNu3QUd9n
jxiWpyH/CESNSPI1A8gTymcxQfmDCWUX5IgE0BBUO4GqZBWqqoJx1u8QggKS
FB9pGmBckdsJXJkN8TGG5pNW8kfr8DVCdoxJlcWPYBVxLeab+2TqqcbINMKB
OLFIQrO0xqBqZ1oyxLtKQEej6ilbpHhqzp4rEusaWqXfTwGPoexWzWYyEDdx
FSoRHxmHpYutlCFqALcK4Trnkma1ojhc3SOWwpp6MWxF8Ms387Bsxhsv2BJv
3oppbGRV1XV3XEENnckSc0v40BLkxIDOXWj933aAu3/L4Li+ohWtmMK2+1Iu
33bqz13RHsFugN3FpzqKV6OvpVar1EEh3atZIyWUK8GwBQn2YgtTbHiNkVms
GRatHeQr8uvmjHlDqvRtxR9DZIy5cB+9OZasp5LLbg3tAo9PNIi+dF/oJVkz
TIMBOgRGsrJwDcMmie9KC2qiQ+IR1ZP3L1cJC+rcRDAqlE1fGNuthYCS+4ff
12A7X9yLpeOa9JktU0t2Sgl/ScUKBgc1m892j+m6RbhItmqkD6tDs0EdwKEZ
tNqn6GLNSPmKcjeOjrDAts2cU+dUDCdDfFvT2DmPlVNrbV0oKc3tqQiNFr2t
ih4tR7BW07XHXodWM2IUPnVOSKSG+Cjwhyuyu21LF3DiJjclWj8ERQWx1udi
wcYDjocQNVIHzGhebgReGYFI21WZQH4gxH3UCGbQdVflpqhOE1VPo2DFOpNi
3YyiqkBZeKK0TJeCh+NyUlkdAe/kZBwGxva16hnCZKIch46JU5jsAGBBWCq4
Sl7sboJ083lVTG3ePj9S0wmOCp3tiWLeNGG/WfIJWl7D8WXQ72iZUNhQTTXo
hsQODPFFSSIQXFHT2cPFCbRFqXjcA/4UQTCWVHRF7O+ffToa0qq8puPmDGBv
JnVJsNzOXBOVXqYbGK5fgFfZdemLp568fPNqN8DC+HqdFWW74beUNnWwt//p
k4vr03Ug8taK/Kv6OVolmyXAd+gU0eXA9nHEvV2WYejiSYlYxIKnCrEoupBx
h57uGKotgCqfbiTcNSyCf68xCbT3EjjZ1jk0hp70AtgPvotjv7pRLMaJz+Lc
Otgi8A2dfxvShPKF4oXrG0Y03jQjrIPaZGr/kv/P9XA2vV2GmQob4r2P8Xxa
BYMZsg9HGmZhClHMcn+H9OzFzxJThusw6eqNUdGcLLkmepFnm9HJyZKNQY3C
ddso0LT1O2jUd0BJQMk4HaB6Pvj5+Ru8kKBz8t+guFL59C0bE6H9IaAtcEwE
FdQDlTbXSeKxi+Rc2pCTdqnlaMiO1JROueA9KsJU+gV+2Q35Sq0YfTgGzdKE
1sHTLOYdHSqJ77nIImRrh19L5EKzOG9eJaa4Qm/LvHpu5x0RrXz6zrPuvG4U
4tkfjI60CM7QlyvDl6gGGXxJFb/YPM9Ery/nwxDUZlUn1105KWlWTsILbcEm
/IBRIw3VB1sAesASMFmA4tKITPWFFL9927P127DibZZSYZWGEVBLR9FI3iVw
Y9Ol4CBonB0mngggNd1aijChYlkKO04n6x18sv/s7d7e6Gb0ble22KGpZOV9
43VmR0XniKAIBLfWYjXd+ooswmJMQacord/5xQqFQTAKd+XL4XAZSoZWph32
CZq11ugZUHeOq22KCQYJXJGKdEBeLxupIoU2RfrgF+msEzQhhgvmEhsZvfFd
kJr77W/xXPpiLwIl1GKrHeeOC4I3Fs9rzo7RP0TRb7PpZqFWgvTuO1n3BeZU
qcQdPcdyrMZgIYgxPdPGQeuEeSfhqYU/x2ZNW4BH5Pg06Sm0PnJgJdwmYD/i
g4UYg+Yhw4pkLPElCRmAC4R4GLo+V2Wog9QmUJFtl6zgAdPcow2EmxtiK3ot
aUiAnqdTZhhmYqpt0W3+nEBFRQQVT5ko58/oNIEpeDtf7OIQXSqwZ2tf8WBE
JO/jjAek7aoDcBxJa0H26CLkPgTIr5WUVxhi7Dd2YpseXCmLrBu9rMIXTGGA
+fSJBfWJbe46KTuuck80rO6JDDGs+oVGQdtCDtsG1U98ZgOnnlIXKMe8xBp4
jYpfW3gQEy2hBz5iPhxYHKeBnvEBzH6AfWMqQhtPpM4bDhpjj83az+Cxeftn
Uooe7g/3sYTnzUHv7V9CzrpEs/iaGKhY4qNcl/zhiJ+k3w+iKzGJfDHBCcsm
Y2f9EOrXaS4nLlNzdCM/OukAE2y8x8eecDZN49Hof6kDnLICzDT8B367UXe1
nrR+kKgKo5MI3o1DCMP6BrFRPGZJ2qqATSoKaghf2E7H23lq3LTWle8TvAyb
Vh82ko8B2wcrq/Wg52yhRaEa3zGclNkzNYT7jjzGEYh4t+t5IXCuJCoXOUeH
cZK8j94J2fV3N8AY5uXkPZO7eBRuZe4a6q35SqPgYCRYZ1BC+jusJArbpF3W
Uj4kiUPHyfuOUQpx0j8OC+VdgmGi2DPOf5X0OxjXDAOt8JFlxYJManGGAvmw
zqExgzGggOxZPRc8xdQZ0RkjoV6yYykYqAHQRXw3AuYhwtU61j5gNAI8CpVn
lBU16UUDEAfldL1aMetI24oxR1yRrdtTFx+XoQFvFIvk6ZwncRyPwRNzXlTg
kJsQDGKjFNq4pcb5iduGR9Up+MA4rXHnPgNuhdS41PhoY97ywJkd/DeEVZuW
JyHHnc4GQWvJZXS2ohk2IRjUBl5VVl4Kk7AwY/cQIWaLxMTn2mJFrlVtyKA5
cUpox60htzxGv2Gwowf/Vv+hWIFICefifyFiHz9Uww8/0CWqkcn2lLRZVGqJ
+HAA2o3GLmjdGwWNyetOKDyB+IRv37PEw0AFjXInMXxnG3NCQLWk1Nywo0C7
6m1dlTpFV2T1YQrUfEGBuFS1022p2nlyeXp+jsq7B2PTHrwWTjInC+q7jrvY
wHA+cJQ9C6OCnFYT6a+0onQ/FpKDhi13zpESl3n1tu7QrjpLkgpIZhxNM5JK
o1o+81aLh3ZVJqWYHVps9P9SEU5sYwY93+GF4wpQRIp92jU5zhqp/YqPa4RV
LPXgvcemjhe7VDVaER31Pjd+Toj3CgZka01SxGy4g3Iusw9ZNcnJRbcOYSMG
98ocduej+zcdhQvlDuXL20MMXxClXKMZWtdKE2HkZm19jatic0ZJO0jZUkta
jdK1MJk4E3RL6JY10VHdeAKhcR6duAsGQmCFWZe+EZg1kw3ZCJfT+NHuILnm
IOotgQkiDsa8S+9/WBgWzeAQuDjXWqKqDDR5KNJAaVIsvoYwA8yQsEDmAW0u
bAH0xWlPVDBO7C010FvcAM7xjR72/uC2j4vzAZIXkrEn7hldMhfhIJkRMCPS
NHP0KQLlB5aJRa4SX+QKqTL7M66zUrLYEPWIJAy5f1VGsFoMtKVAfFGVkq0U
1Jew/J2Wr+hYa5iGiZNgUAKu8SuoI6vsw2qdzpW0sVf26Cl62/j3wz10B3yW
pLrofjPdb9LV5Cvoqk+w9VbttqkxmqIpNB4IabKjRpWKKsCwE5nfGfAK7A7d
S8QzosxFvUdcK8/aI0xPHniWKmF31arrvFZULcxQmlJzQnxhNqH9J8rT2l3n
Fn6GjFABEOZL6BvcYWD2qBpQQMfvwT/EmCaOdkEkFENogzGln7w6uXp0GPUX
kktdY3QdGh76n/aO9hjmNZBH29t7to07H2rZSAnvrqzKwYFjFNqiohsS8dAS
KTXtA46I4SH+YFLIESUpoUuj+fRh42k+62Tp9O4aTidcUSnhCAjWBLEYQVnC
sznUKd0COKF+BQI3CuJqVKKBmEKrtKwgf0RVzoLDYcZOX28L1NKALnTWEeik
NlNDnEVIktqzwF1WXC6olUC/o8BfZD27A4l0lVGgMWfRN3fNmZGbhB3lqqBX
Zj4lg5On1oWAZYU0U2RUNkpJIIZEHPGQ1Q0BZBCwrDVd26Bbc9hQXPSiXf/G
v8BCyscHts3zohWR3jeV3MWaqREK6MsxQxUrFpa9kOI5brYuVPeqME1qvonq
ynAskt68WG7DvHwfed+qbCJ7EAQ7MUXSnLyhuQfiYYnxZiwfhbFKnaOwFjbX
TWG/1cDegFlCmTKatikOqg5zVKYbC82MAuMVLwhtzpSjJUi5aKjNl9uF+TAY
u13fxGyMjQkjY48C0Nk4XOdTm2tv9Yy79ubGvFJnRVzHN5hZ3HYtvvbgAQHh
xFgFtAgsaOENHT8GqcNjZUI/JiuTDuBzJwKC+u+TfFxT8kkakg/xx0YmeJZz
bFeHu5MrZ3j/vGDsDIJbDju0A+U0ewrFoFCS5TJLq0RMNMTD+1HYiD6Bg3OS
GjLR+nCtqi5tF0+fpg0jpaPm47Zc6NhqoN4itF3jdfcXz1p1GEOIGollnI2u
Aosfi4TJ++hzzACGWTw6Ojg4eJZ92Oc/Dg8P4Y9RONnP9OO+vkmkz8iHPAgf
AGTL1fg9jhRtYnZtTbsf+ydJGkZlmyTjSZVxALC2pMr5VdO3RlYXKn+4hUz0
Yxd+2DqMpEZIp3CiVe37PMWxdkZ7DhztAR93zBE8Jw6opXsRqB1jL+olGg5w
SKFS1A0Vm5CiKVTmOuG6lULHku9zMmTUIUwOuBOH8mGJSwmA2QRjKT0n0cIk
ddQmmCLk3wrPcDFegVjf1G+mwqEYvoXNqHRPjg7R8jlMzf18cZ5ooBnKrzBc
YsHmbjRLJmFrNC3gFwPEGZVw4Th+EWMjJW6O/OHbAvv8fFQx1QA6P0qNpWsV
qcJYM1Xwm0DBaIZZrprIueTel5nrr6H5DmIbm698so5cWBLQrq5ehgI1Nvzc
1sLVm84RtKubRo6VrhRJ9BSU+In5JMU/ryQOmRUhp+tcC0e33lwNLzp/Xqvk
KJZEqYnkXV1DCafrvj1i+2nWHSFphAyxrjMCD6/SSZzoEQt3Rq9aA48SfmMA
fUJsZdBmpAqZx7ZlEYeuM1zAUyuFqRVQ3NwByFa9rnq6EF/DWUh0OnrjlLE4
4QEiEOTH+PjxxdnV6Y9Ud6UBt8Olxb3pMXi9G9bq6Gj5GDh/YRgXUGV88sH4
iDcX2dpCcC15OmtUITJJQlGDVCsCtXaN5IebGlFwlHZICLk/ViFIHGQ6W6wk
vi+whC85sGGesTvBQ20YYYeCLFLHA/UYIQGDweai0Rr5RdFUUDUSF3iha/Rs
cbKNj+oiWmTAZZQSk18L89mm3nbjQtCkISYmUENkeX8ew6JoArxN9AjPSVAm
Kz5/olhyBn5SYsmNCCPgckmN+dJKvcFj+obCipC64IruNGos9TlHC0U5rufC
nOBYJUjZHYRPM5TUm7Hh88PDA6LYFpydgNDw+AGl/5NUU3dUtFuPdFQoihMU
gmL6Te1VUxkgOpuZzdFkKFYdSez3mJezKG/1zsXR7MiE9JNPn9xajiyj6ymk
csB9VKdTOZvNMYZGoGsQLZMrojhfnk2QrG1MO9chbUe1J8LR6YLbWUsdtmYp
uSwu4Ol97RqZ33ec/RAgYbniKdcF08vFMARcZFco0+nzV7Ss9S5DAKbVyoAe
+ZMT+Fu7hLXQFJm9qO6M2y16dK6OU5viJLC4fC1feCEWxsu9hmwLuhuaMuDh
7QjunctlC+qNFGHyd47lQLIjwKyEsiBJwTHqye1K7ff8T3I2AvlW9LoG+2Fq
Ry4YqbZAG1iH1Gotxh0uqsctp8OLhRX/SiOMKj2bnMqaJe7aRMxzY7L+prLV
ppF0G6WdoW6RF4yCL9BOnGGNWXJ81zOnN62OaiBIVwJhHyqP2KBx596EItix
icSvKowWIxPIhsq2Nomzs/gZkou+8sk3HJMOkufcgwhgJW5sVYEyMZFYng+d
1ZFFL+rFhVdouZuN62X9sbzLCCphxQhFGJpXLjKn4KGTADXh+zL+PzGMqWFP
63CiFEUQIQ7rxqLpWyf5gsZBSmHdN2dGyobRbQq1nUUaY1nNIQJlyGw1p0cE
tgajXteC6IHhdsD41qTg4r0qsrlzluzUGpqthaap0hjjjpNhpgYOnarwoTw4
pzjEHaabTukmjg7WxPOWuJy8tipWcGm2Twv/+s3V+etXJy9BLkPm5pH6o3w3
ijotkcQISBXQisbcklBADANKcVmrklIFCW/Gx9TgrXa6McZUrOgwAqCFqS5z
D4Q99fj8NIqgTDBMW8MhrbJ5bNRravpVxtbkKB49bkj4qI62B1QNzRnG6O2N
ruweinw6BL4jGTui3JRcx6W9enJiTgkeZZ7PMgRrIXFDh5l8/TAXaS/ZWaQf
ErgLu9ZAf85Oxw6HABaHFfyn7MMyl6IAOAi9iHgwQHESmc/WNkB1iu+47n4X
CjCNimOofZqmjLgvicgmhBwYAolsGcZX5VwVuJi69JrsyYifVS4MRk3NkLNi
6c0+rDJf85CXEq8QPO1TbsfZptRIAk5VhFkQw2ktjZxJqX8YdDleKB1zTqj4
lzcYxeRjPXFlpHgKiNvknGSgTh4qjV0sTcjULs5OX//009mr52fPQ/bcEmPh
CT1owSHkKONEecYza+QWuzelafPKIGnwQVcI1ZoCSUU3KQHBm92mrYoHx2Uq
tp0adUh4iaQz/m5JG6kLz3gmpA9yxZ+M1SUbjW386HS/4VhVGmWPy4r5dA04
fbo9P8DUEG4Ni0W4SzlQeis8/2mWFeD0RoagsvfIGa4RICfnc59z6iu6/moA
ggKn7LvrqlwvSWSMquNpzGIe6BsPJrI7DPnyozTVj5WapAvVy2vTxEocmxAG
wjSvw8KwsEGRzKnBbPTSRqSbB21JQsqoN8r30WXVSN/A1OieVpmCqUTxtwbB
SBAStZ0GahRcVFDQM6kNGncwi/cJBbiBF9VYdDGxco5tphbJR8vNxUAaJpnJ
th5YFGcLFoYpBQuSll48N5U1mmrGN7awrfNFRCQj9QvFNncYdm+717cDEgYm
z2L58cOHBsWlR4ib9VYpcHbs3H/913/R2JVTHyc3o2c9WGnFYTkGlbTX109H
zY8PnvWOn+Dv2FJUrpElEr+9sck92uhjTbLynQ5jeJioyDRas57djPo3B9Be
iQZ5fXvU/bp5Gx8ah6e4qbidv+JshqRS1DEkTtzOQWgmgNQQHs1TaKBjlAhR
871RCshiuFyv6qY7ousEC7gRa2ZjD09LUAoci09wNo19e6ffHui3ftTHT+X7
F6aWZWRzwEA2PTb2Zst55L3+mlGLoNca8kHnkJMdiRmObqsMZBcxHopNE8Un
2lZqgYX7rXee9hF2zcAwmR5EPdQEBSqhuOE7jE4+u4xfGq67NJc06cFR6LG7
yQp5QtAxVTSq6WOLOw0byy09DMhIsn3tw7pznEs+s/AhXlpQqk8DFJEk26go
1KhxrIkATo9CxykcfeYYmktFpOOdI+KjlB29BCJvTNKq2nSwTG/tYQ2e86Rc
CsLkrWZi1DEn56ojosaCqD7EnG1TmFmBQUbDQzLU+/RtG0np8yupQJswUrv2
DShr4EbY6wQmBRpb2k/IcqStmF2MIgrpNMzxRlperHXFfHxeKGyiMZkotJpV
CYHTXApGzU5SvIecH+dsyqbs2qb/RkKr2rYsm5fWSOsie0h3B8nO5atzKv/k
bMq4Hy5XmmCloIFb5yuPqM4JagLWR0RQxDzFHJiOgtk+Euzs9MddKfxg4+Xp
zmIhSgVNaJRmDLYkHRGMH7hzwWlHwbzd+7FETRF9VsdeOuntsgjoEwjCTEPt
pqjmCBaaxeYu2Unis84Qs2ZNTquPD8hcRjg9flMYHLhZCgzNp+uCYyhCJjwa
p5gMsHqqpn+TWmYMSV8azccfL68u0QRCXjVO/3kvonHsjRAw5a6Y4QAiy5XS
3MrmXeYzIxWyJkauH82JE7MaZ2uCRldG4EhKREzOXqxOB4fTy1ZFnYuMQ9ON
b1ZmQ+spr/oaNuYxbM0C5Hi3L63fk72+jymiD1DaoAovz9lGxFbKULo9pahP
tWZD4+q9j6ztGJUS4A4jYOYnwwMyDtNu9RNO2DkaKqhmw2Trg4js4rBhuxa6
p+Zlvy2EUp0SW/Y+5C77Za14pdZxaU+F80iybO6pBWsKHfteFpcxJwd7j5Od
qwwrRGNa2EXGV2GX9Pw1rs80c+Hw2/kImem9lHJqPZaL0dx2gd0sV+IGZBC7
jinhzRPm6eCKXF/70lmC1u1tlrvue4nWi3U7Px81FZUzkB8GeSGXUq1taADc
7ce1HckwPucACAVsRTOTN56htTAlS51WfsDqJlOziNuXz5N5GthkDvo6hlUr
qpC1UpvTcyMseVmiFJSzb4p2cV14aB0pDUTHBVMySNNRS0ZKtgSCDiZ/CVnE
zL1CY+W6Qn8Pu6adrrUv76xbHJ6kQjXe0uwFCYPKoc9qNHIa/NCGs1M97STU
0+byFz7eyrfGe+csQRUuZF8yDgNTJKJv019qBw2hXQ2JNZrYMOmdKlqjyLqu
6qwnEkCwcdDXKOJslqmw51qpNfdtwHXx5IAyITHQDcpdN0m3TFtYtWKgBgOI
BAvwfuCQK+LMOCotrMLf6YJYADvyOWZ+Ck5nGGDRX1O/IvO0PUKrUNVAbwdK
ro7ygM2SsTOfggnFTExXx2AGoukri2gnBaI7/Xt/xBj3yvoc59oH5xsnDSqc
jaY4cmgJUa1I0iulwGop8yMcqjn8Lvm0EdUQrFEKmaamNCw0JXO0kKy4Z4Z1
Uo+vZ0us8SMvaVjLbdispn1bulVM44AQD2n8aza+LCfvM8q58H9QEazDo6NP
n1y5ZGtpSI32BuNfD06TFwTkGAtwPrjDpvX4wTi1Dr2TMwrTeae3OFofSlCg
wjcfVkJWyJlJxEFJiJrbAhCXOHobG6bch8p37sYrhgVkpy0pQ0fchcPu7+d6
yRk2Prc65uYkPRYx5obzwSKoZWKeiQcNIGWFoduCGkLxVgoh1kC98PjRaB+l
tHVgFFOOh1FzKsc1YVAdpa1ekuyBqgjdAv0TZ4xw5JJeNQeJTcpGM8pHG4x8
kkoOBtloQ34lUyAJpAqREypRT51APRiXv0ZTSACbnG78hGJ684nHPGTgOnY0
SeU5Tag27fmhjY3lrnuAxATqSckR1LP8A8YDmlSFVqxIsyIsQ83CKmbe7qmo
d4wK7yQhPvdl8pBNqw0eLj8VJGX/OekAXCPRFDmr4V7VMwY3c6EKUYR7z0EC
fck7CMEPbCKJcRx9+aLg5+9aZ+EX+DIF8NpxqozOY6VnHEdg2IHHMHFyFIi4
K+DQDN6/nVjs6HeEPYtfHD98+E4DCXejwhZc/lNrVqGngeuqcVqK0FLpryAY
h1WJ14WrQanBLHJQiJPAO5lNfqov00hJTB7awOEoCEMAc6CXWucrCs5RUYMW
KDELJDhp7wTGG2Y7bK7D7vAzF9T6lz4+aNURoGBTXh20rszTOLvC1Er4fKkE
F0V36K77JCFh/Wx5aZwxm8vj5JzYxFBrc/HlEsgcQgEsRQQFTGYgF1k6yRcY
BfLhredaDl+Tmuoo0+KW63Kw9BCX8aBY+5/ZZBJilT0ll6oEYax5zaUaV3aa
XYFeEpooVMJZyqrhTqyX94a9gHKsINVkOSn4RAnK2b+8vjj/4fxVElm9vxPp
i56A89UGbz94xFjxTCjaN1Ht6ntP9viEhla+7tVxWnVgxgtCPW2NQXHnzp7u
Pd1jVPvwsnYmmPb4hQ/eR+t/5xoQCv13PoJcAiwqukK6JDDoLUsiXZmUAXUz
dL62ZU777uNxsspX8+xZj+kZrmJkRoW15bBuLpkuOGXN5eSsDpg4NNFA/D/G
FUsE9BLzVDjje9gDGvC86/IyVVAKYI+q3DWgW2gq5bqoFOqqTE5y1dZFAHXh
eLf3WSjuASNBuzUrLXNsHhNL53UpDKT28kfkEDUm8lDI5InyNbcDmgDj3Ylz
U6lNiJMTusMR1Q1vvVYvyZjac1IjJUTxZbdmQ9LmmjB9SPLZyoOLE9J11eVZ
siG0DqU1VNkyAsZUg9CqvFzXDfxXckOD3F0P1UykfoBCHPo8cKZwHmvebKDm
SkkwjwkB7TsBvEWdw/vBzasYjQfExrdqZamtrUqJNz6LNXv4PeRrVtwgaZUy
m6eKXJxKXpAIEzNxoVWL4/ga81PBVQc3md+TT8I9/jd/+fCv/aej4R4Wk4qr
V7QuJnllLHNTZKqpgIHyxsqo/i15POJOmu7MA+dsdh8dIPXoxnMIRmxEt3Jx
np9H6BLvlcXZIgRYgklDDVByAwQBVvxgAVXL552yDGRh9VniQu+gT7vH8Yh3
unvQ5Ofpi9xKXal7SsuQGK/r5xbpivymPgJhTtXuNC8eIzYyg/LHApU343bY
b+mkOkRFIN0UPmuvt0yqe04akrjMPngJNzqmdD6VJPKVMeG48GfjwDKhmtoT
e9LVSErWfLY5MUAKtvIdFj6U4ygtsVyEhUesZKcBMcuynNObd3d30UnXPeDB
4mORYCm90bz1+BcJI26ev6l9hvKpxKsHoocGC7EdwMtyLbawweQzV9H+KMuM
r+avGjV+GfI8+Y4SAl+0zv7o52LHxMEl4w0CdXDkV5TK3rjV8U98fPc6Fs8A
k4VKMYJKRm8NLi4EjyMKKNI0EjRiOrODLAo2ZkRAoHd3w9aJwrJ7WJoUWuTo
dzU+9OScN954CDJLz4R+D3eT5BVc/3ikLhrpf5I1OiAeYCSXVFhy7jI4maR2
ejAxkcm4KBWwJIqfJkYiFks1y6BCGfVsw7RD1eSoCIPz9jZ1C8CkO5bKpuO1
l6VHhSQ96ekL8ioMIYoOl20yNt86KC3zjRCQNz6edMw5io3IAXN8EMKqyhco
NdkjEIM0Hih+Xk04aOtl9Ky6LlQZFmCC7MOS3J8+fSfIUl2s1ZxoolJKkFRG
ZiJBHW4l6Rgg03Gv+bFRImOXZzm8BsmuaTkmFoZejDraZSqRJC2FQTra1lbX
GDvaOgiuuWASIN8cwdTNIw+ZB7ToRdyj562xzhdlCD7NaJf5xmAhe9rKuP4V
7bE87gwVbAZe0olF+xYTgalKEZcxBAxRCzXAPjzwcAZwdKDrNzESSG8MUvaU
aAaZ1MzZo6jw5od0AOnmI1QzGivVltm3BpR+kq0mcmF+QgPLALNwPj4gY8tk
WjTTthoZDLE9u9ZMNBaKKXzdebMNXEIpmbSizcOolODMCVHPp1xPPXmezYEK
VBv3StAnkx0YGygRVL9Xn27ekFBkSjAb2X2dUg1bSpjwGj8aKjU6liznFjqQ
DdMkqkUieqM1a0HA9mSyhJLN0DthAUJYdMNMhCDgU9hd+H2jG8Iogyqf3qBD
St089iYIFCtS2gnwB9CPvArquKauWSvJTxBdEMMC/FdaCUkxEUjEpTh6XG0m
/fPyOp9Qf2o621L/XKgaUDCaBYlaqqs8VMe32XCrI+qb6co8QQ72epAXA4kV
vyKLdC2F+Xow/R5Vx5WXycBM4DseKFMtzNTZ0A8QQ+GxTd5YGulNWh/z10qW
mys7JDnN3Bd9QOQ2fhvFv6dW4oPrtD+Myv75Yfik+4QHkwd4jS+NZVtn+lxU
ADDqcJOt/uhOp8UBdnjQ7vBXJc2BAVbZQrCdyXCeSoaSRGQquNAfshffJVcq
gOai4xhZHufhq1JIychwxbiFf+uUQ+FN7SCIb7GUiQQeNTscG4jxXRL3CbO8
A+CL+/sHwyddbLahJ8PTyGe18wufdVQncSnA1qHTV4Bn3qj0Wxv3g725OGZO
aTaX0SKJKunTvN+HB8N4u6Ljju2KZoMvYOuigeAoWTp4Egs1NwfEzFRZ7ViX
JIg2XgLa8lxkhtj6ULTO8PTx8SE/KmPxAs12SabdxmOSZL68W1239it3zEbX
yd6xDzCSYkftDRpZmVM1z8DBqSVZLX+5DrbIns2leGTtP0+GR/vD/b29bWvf
fGzLfjcfO9zyWGMTQJh8/NVP7n/l3YrJ3e/fKcFZiWL42zt18BU7deBv1EFr
CwyN+aqV2Aci88QaYJXxUwBKBP1j2DkIaSx5+s9cRFAlrcq/MEmXKblcSQAh
gO+mhh5CFAhdhWThgZa8wvI8GJIb29QDGjLjza7ruBj5InCMWKCissEBeAH7
8yjODJ6XfeCQarQAzTGA1hS4UksWxm+D9kA0LlzB1Cfn2XASCUBm7YBum1cn
2ZWVeBywOong4eGbKcxXAh0idPgpAjygRos47EBucSbGiofeTu4qOJ6/ZeO9
R19FdokmVETi8DYwstgF0J3ffPkc3Dh2Q8CoBCeJnQ+aECsQhSBkCsoOV8mL
C8QbHsrZBA3HJ+E+R0zIh+WvSmNtEis0TcIHUZHhjmznIHin15JgiwtB00ch
4aRPtyDUYbA5vepvDpoMx9jW5PIMFVwXKS6CJOkxfjpRjqbU25DC8ergrde4
cXRtrG7WNUfB+MjpCGBYxXnJhw6BMoqLm0T4igFEJOgCxs6CLnl80QcRB5CE
xHtryQhscpA06zEO98bkRw14UMQuDncS/EvuEVUfsSYblQiPkJirBKIcla6h
3CqxfDKpiYPXvIs7oiG1ivl8pChtkMvOG8gSnR6mi3F15yZ9Z8K324dWiExJ
Oha3d/IwhnxGjTKNN9egsJDyn3TV86BtE7aggWa4OoI2SVWm1Frh821q0eFV
CiWxjRHaQgyTqcfJSAXYrC9ZSgl6zXKbET6Jt2ugya6ZFK5o8xQTx6vlg0bL
meuN09/Q4LfMYy/r40dHvWa2linwGy63wjXyDc9pnXqwOYcDaDlycPecVCED
dRFUTb9N9Afu0cOwSxKM0CwpbBz/3psCI0X392/DxhyGXiugpdxLOgflTPLz
ug7AD01AGIG1Eeusx1jsBkFv56JKfI0vU/rxAX3i/UqMw4M+aXU0NSw6ch3b
wLKcZiIVrikGVPJnMHW7mffdKINm+tOQPfaI+bg9NOvuDw8E4ffJ4eEjxASD
I/n69BJTJtIlgrE5/vrR3qNHGHdP/ma4DgIFC2wc574eky6JUV7WO8OFy2nE
Tq6SlwjYPAt7OVYALYtSp/frio74XKNrfI0HzSPSViUIjuGY0nm0whhAtdZA
8FRfHVDea0XmGjSjhNInO4TFgZ+p9xHW4Hl5xfjH/nM+W/jNj5TU6kFC7ArI
5pHfl0k++dMRFcLMInqKkpEVBTSiRh7OA+3p/nQhxGmxaQSdKpgbYkDiinq0
GZGAKMKYsxMwxWolKRNUTp79i+Soj6gVg+4xM6M61rgUPwd//g/zcozFbSdw
JqfJGTbqLrTUtSVqcTBkx1BsJwgfeMlRb7Y1AqU+enqkKMmmFR8G2rkkzh8z
WDgGApbg1dNGDAQ+8zBQEEbKw7w3YMNjlq7oIHhwDCfJDnVsc8b9vDj708/n
F2fPKeABcU82QbToKhNC9TMiU59GU6r6v2NynGzi375N/NuNsvIb2FWEweLj
9iNwFbaW+hQJx2AyyieMmMaxtFHOna37wmG7HvYiYciRFYk3EodKDIzCdBQV
lOK9ZvN1fcNJxipeM9hTTXwvVC+iV43oTS7czCOMMkgE0LyUCWOKnaIQyoZZ
4neNDIQFldaoMHURaS65Jm5yvQ5Rbn7NtaDZhwCH+1Zxm7h3uprt6kw6eIWO
VFkdvwMBd2Pq+21MMdiQBqFUD+VytsYT52+hj08oMo5Me9Sunh2Yn0WzZAVQ
V4zicBbZNE9JMptoTo8fthmxGOn7VBQzxMsY7KOOUXm/opxHRSpKW3knvhhl
ULh4MetoHW3SjDqBxTdB7pAgfQMV29F4892+6MS11KvemHwH3d5JSR7OVJI0
PfZOzdl6OgI/PlhLD3kw42oX0BWJOYsFoRhEMZrpGAsOFBqA28h+5gVlF4Qe
IwTNw8xCTEQicGvdfkLUClu3kTRTOu0mQAzjmlTo0vr105LQm1MUee5S0tio
tpkfJsvVlHFCfh+8whME6PDuJxRIdJx6FZ0GIwDTnm6kSXYherS4MfEdKoOD
uT1FhjYDr2DxwaQ470WG1z+vF42LqlHEZkxG+K4Ya1MdKKn0O4xhQzwMEMgx
/ynqAK+6HLa4Mky0mC7IKp/ZC6xQItJlWqhYbEUdjZliuoy1cLS2SuKBN9R7
GGLaG3U3kHvRUWKa6M0SIETG8ds1sgBFYifmM7c7KR5YT7cokrgAiixFlTVI
Al346YaKsfhyltBOXTMWE+XRTNizWMtto5biHt0NV7NdC3QS2gzm6QdCyqbp
crUrkYcC1/Sjo1N2jX6HdeGFPp8ftXOl6XIE8En5nwI9mlxe/BKUVwX5JIQn
pywu5NZgvMgJjhSkgPxaDFc2GwUO12TN9Rx8vQpJm/bAC2LVMniuNgXegFR5
du8rzZmCaCi2vBHZsSW1qJKh50dVbCRV6VwFyeobkZBXCvdVEyi0v0YS6x5c
uyF0Di1iea3ZXRIN14yV5yyWEmsJbEJddLLhEVkDjpxzLlMsfUu6ExIUy6Ic
CeU2dt1snvHleaxnEVhRFvP2lPnGfW4VmAl1UBK/CJwpW+BKzCnVB9aepLMo
+U4yXIw1NJQb4JwMisZiHqzufCJPghSFy8K6JkrAzR3GLAgWya9ggqJb6tkz
1YWxMVxbnyfEGKdc5JCxcx4dohUcdDMc1BzJhthVqeOAhXahVoULlph2Li52
k6v/eHNWIwEUoVz4WE9swgxLvQHBeMHZvya8AhHprtlgi3M4ZmPAtwxedQzD
gt9/YiDD4+QHLmSQvFlXFEnUgEGHRy80OfY4iRbDwxFc3n+xevRer7FeR/8k
68WWqLBgR3bBGgvEiptqhB6E9kvr9opi3WSsdOGkWRMlE4qu6JNYGwXXgmIC
KaGR+cyENHdZaH24z0Epc5Bte63WubDDjkUx3+3pTfQDsxUaKeQcAfUpqTIA
YVmWiXSX/OAWhJ0JiBQXiPAVuWRBq1c0rtyklWL6Mulp4M+7QIE04MYKoigw
nKK2daxrs7Jd9Bl1DFcLt94sFJ7SViWAHex8t2e09q86Vg4P8HVZ+fg9LdOK
0owMhWk+qXamio8NqkPQgZoO5ytib8dRATGt2ZBLIWksBlahJpfsDai8JGIV
4SiP0akERybGx6daROZwp0hXq5VA8FJqNcI/cV/mQJMazZnksR0AiSu8cUra
JEU+Ee4njPoNLElJSLq02hsJ9CGD4GQVs8CZ5dYCMgkSKhoG8WKIBcNUN6F9
kPL1CaWEUGUDdOLCSHxdi6Q36HXXObmSEx6ywxmumQPB32cbBm+RsmSEIwyH
Bw0qucLT2iPM9eW9vAuC2dmHJQIlX2S3ebijHI6xLOc5l0QhU+H+6FE/UZPD
4fAoDBBdbdesLmXcXNMmQNpYc7sStlaOJd6XLA8ThFcMhRpT9cYgZ1UwEndT
3vliURULhlFNlW/qpKvaAgaghCMqyLmtQWH+8Zg1Q7xnoE+u0zm0SBZgkK4H
zytQ/8lckQaeglzABaFHGAHtkppsPKQtZbngxEPZKZky44ZSCToyieFYQhGn
1lBLBsQi/1HvUpDEd3gEWEAHT9+ups8J/KKIxdH6sFOqIgoKPdSK+aAQ4tCW
BsqlFd1iC7fIrU5BxJqXS/oCpsckzLOMDjR/5x2aPoZ3gTo8XWAycI/nmVCo
c0kmVr0CWFCeFumASlpItdEm/2PiaDiL2hF7SMUJ3oganaOVGggH1f5W2h6u
sXrSKSMMyN3fhdyxG//vfMPNz9+VaHW6/fmJ1kZuf7RFsJK/wxAG4SfRv+xb
g86fLz/R8U7HozSEvWiYoTyOX4W4YI5SImCP+sROJH3sxtA68Sqcn129aKwM
DGE/egbjYuK3TkLOQ0fp7u4hYCt4rOIRbB3CKHqmUbYET0cZAaF5t5Ja5P+A
IRxEz1BX0SdvtPMui/OWjWgXy/70uSEcRh16r3MYONXEFM2Uq8s2pvaFIWhh
4U9bh3AUNZeB5BV3cHF2eXbxy9nzZMf6VmldEGMNt+rhSfJVP9uG8Ki5Co9a
q/Dof/EqPDoaPWH56rBjRn9n8wEInQj70j215hDuvwpUO1yfaQ/hIpMk3Z3e
OQstSCB6u+GJf3AIlORKLNBLPevllEreOJD1Ip9UP1lihfpMUh6tfMsMWCwd
sc/Ldfi8PHchFgFUDvU+GuNfX71+fpZQ1G4Xb/h7iw1EBD6iv93EuPkZNcAK
B3cgmYn8h6ABoykBRdvOFf87uchOJog4ANrH9SLTcjYXGTPJN+JyrRX9nZxw
rCEDB8UsfuJb5cwUy/GhPaVUa002WVr5muY9yS1kgY5wWjC5pIcSNnA+bE7b
8i4C0U3cx4//ej54PgQmPc/rwbSoy+UAZz1gWxHstD6SZ6uZPJCiYK2uRJKa
uFZXWrxPNuUaN/8cBJPLu2wF8t5FOp8hVBBauf4fEJousmzadz9RpjOMplzU
aAV6uQb5HoWO6RrE13OEs05e5uv6NoVr3HdX+SL5NZ/kRf0+7ydX5WKxgYfX
mIF1elPBJvxaltN+8jwFsTP5Piv+E2v1UC/vk5MCSMcdKJZnVDr6EvSA9/AH
ahCvq9VNP/n3DdY/g/Xpu9Mqza+TK7TTVtgcqHKTk2qKIvX3oLwUyfN88h4H
7H4FcghK4lVZwtr2kzc5yUovUfaDv9ZFlq2SSxyUez0HYRi+e1PmqyqDEf+U
glJW/i35aX2T5nBGYHrlIjlNq2UqGWXBDOgBsXOMwsumhMFKnvH19TXW06Jz
IULCFCVsdNTiaaYn4Tg+h51kwwaaD2HNjfz48cFUvsWMf7is5jsKEcfAxzkd
R28DIKN7NYa5kK0eNLhVqLmIEEXjtIalPbk8PT+nPvviDNXU9Wk2B8me84YI
zZtHoOXT0vk1+nFvFo45v46ezq1XGgdsmqhtXbsI1PWIfbuggO3vHRwhYNKP
eN/uUI9bLGAoEiSh+akEy8x0i/ybMggd/Mn3r15IoM13nActZfig/19Ofzy5
QGATmNzzP/38+uqsn/S+68F/dvA/uz3e1N7bHgfM2tefJf/tw2g/eYj/HAxG
j/m3k8HBCf12cDo4+p5+O3o+eHxm+p/m14ztEfV+/sP5le+DH0mkj8HoBTd5
EhqC1R3wDuYminRvMDo64iqBq5sqy6QheDhfoKeEnuKphAawm52kt9eDTnr7
vWQ3GdFokocdgby9UQ8e3sHR7A2A5/KTu/AqNHHUk8+P4JNdeptLe07p3We4
kPBcmOFDMwx+nvJBr9d42uD5/W93ojV/6Nvjp/+2JkxgaZ13MIF3TCs4sD9D
v39Jfr18g8OSx7g3OJRyHuH96C1uWhAD9Cj7w6XeuXemhXeSwS7VgpEQvPv2
9enV2dW7vuOziI0K+A0VIdBSoeRW6kvEC6lj3nsEeuSKrX3sWnK0AtJI6I3C
C3CplhUWfaCrT8vKTidOUHonq/fOX3usPSIUSHihRBiFmZIxBfi1VGrDJNzm
XfYLJLUQo5e9Ap4KwNsY1uW/N5v4H++QCMCdT/DSY50vjAe6Zr20XK/wiiNH
pKWJR6z56kybaJB4C2j6HLsYKGl3hV+gpqbAL5V+pcqr8RLjlzWHSGaLOqbH
smqxBY7iJLv689XJIzKmrZJnE0clFU40z6zX51Kbb9/2pDtCIAMWlaLnZoeq
+ypiBNqcse6xNOvx8riz4a47MRVgxQcpucvQwIo4E3QooW3lTT7GD7kxGRBh
8sJgHEE1q1dTC6vMNwokNk8aNeDj7ROjswvRxR4h9B1DOAwaawjHdwMj+OCp
Og5r4NexTujSCWHVSXgaHj0cfpDU7gH9ZJo9em6o94sX9KIMBt9Pohf3v7Vt
2mebm/8s+bNt5dsdHJ35ZPcvHFfbxKEJkTtmPkBLqZ4vNHQrJbQigT5QCl4u
BkvMfI3kjnnQwlm67WdLtDhaOmAWb/vEM2AkSrxb043a4fnaj3DC/nLC1Qpn
EvM8llieR0KPttKcZhE4BfNgsSMm0JHNVBeih57Q/T7+d0T/PXj7lv49fPsW
jzc+Q4+87b9dvk3fVm9Xo7d7h4f86N7TkTwMv719q5gnXCuCIUI9NuTx9ln4
5NgZR3xQbDKWufcR7ERDpWS5jLw9cB23cyfo/OcEyA6CF4QziQjXWui+MBn1
m3IBdBoUiBPJO9yzd7Xt3v828r8dyChQhqXYgp8kcOCS5LeNGFaZS5FuzPZX
4l8F+x5uVdrb2MqQUR1m8qVimBNVhCbT/AtGlvfGJsXPpGwHX8PN26e1h5UY
Xv/elne2/dznUfePGR+3Pgrtfvstri2qmhQ6+u2328erkWNfNd5vv5WS4FSc
27dftzqQdlFavqtr/gf+KyZ53LMBFRfa1XbFW7h9pNouq+07j44+Yw8x430l
Nv5Z/uFzbaOBsmAvseK5A6ecI6X467+8eX1xJahG77Tdk6isc7Dxop/WdPT3
5B22966fvGvYRN91j1dJkVpI20ur7VIjx8nbP4eS02//snUdLkVUVmjare3S
fVL0CB9PuLVd8lILdBsHoywYwpzMEb4TWd+v+UHDVau8pjHZsqWlHYnL3uZk
MgdhmUp11dkCXWdcB4pyqGoubjbeCEq3+nU084NbENmGzToUY0qCC4Osquwi
1CcaVy4rcZeNfewgmYPqLEOA6HUBH92AyJ9CrxPM7FmvorwFtP4sRGu+KZfw
H6knSM2OlVYJYhvVzeM4JB+RypDPGIJUG/TSqoSHFhisyrlJaHaalAtmIKBp
VyuCkZxqBDkmkzqKi7qhjCtNBYzEDxGhTQ1QHwCCsUmyIRQCHGKVUJ+/+OXT
Jw5g9WUjlPIqirxKeiZGsO9yj02amiIZmA3H0UMh72lemqB3j75hchRWoZAp
fgD3wtQyJVd+FF6FvtvNslnCvc+AHMCi2IjYqrSqtXaAA4asDzpBUdFv74gZ
NvoVQT/Xyhcmthjd+tASAh1XekmhG99UY2y42lJNQONp9WZz6CLldXK29m5z
GKokhPPWaD2Kh8fMUQUiktWgKcd+0GYfwbfbu8swHrXHETvFOJ2jp3iKZtRp
iTiziGqZTgf8BQl6EisXp55/+UVE0RFtkvuksXugRUIHjirTmGLz206+t/FK
8CTOzte3/bJtVpRsDK1AxR0rhIdLThoUGoxtMb8zX0THltqBk0bhFUi+XmLX
RBeUqGk3PnbWZ9VS6qqvk822ZpitbyIJTeQrQdOokwAAyrEIHrlLjdLq6/En
atXoEvcaMU8nPvgfjZ5fXOQTA+PSXOUu83ZzdZNodV3H6p7+GK3lVdQAJZT5
AiIKXUolVDhXAy+n2qgQMn/OIHQq1McZLmXlYkQwjP/muqdKSIitaXXyvICj
nM/zu3zyvo1qV2/ZtvvsvLMo0Y0Kk9gOZhgqRQ0lWugufv05ceGcJL/rnJzP
sB7tvNxoxEWU/EehNWuK752t56wKh9z6uC3ONp2lwiG1SuxJ/dm3UGmaYxCe
YBMGdFaXzWZl5UFtGb6K0rNZCeX0mi0Jt+KY4uhrDEKSeFocXlf+IxJdoMjo
ENEkcIwOWiC5X1Up2mEENZor1TqZhTrA1U+xsZU8cNG/qVv7ohmjY4UZpqac
doMR7TM6Q1QcI7vWYhhzDI2puwuoqyYaJDkuOWyhfU2OLMgVY4xJwRz7vpcb
6hh8vPFOM5O+7zAh1CRAUNqJqL/KkUjtTuv2+ExhdMZE1lKZWB2HJRJYHnKQ
NFIi07xik6ria/pqMVHtYnESdaQQESw0mX2Y/zIscrKzJgro6BpzSNrapqXT
+EjEwztHyME2opxyW3V2CEmLE4ZdJPg2qQeEQWliVa5X2TKIwZghDYSDIuYv
dMQuwBO0yEez0BuNrg9iSVlwfruUb4oQ0bmGQpJhJiINN433VxLK/QHgalji
Vo3IrV8dsmuuFIDCFzugtZqWa5J2qOCP48I+tNKrKvcwJJQAgulrPmttGgg4
BZRp/Uwnmc6xHB0APigMNbnC1NhbuPRYspmtRivzUaK1Isn4S2MmUAGUeqQG
nsncDPk1riMQsO8rPUhgoEQ4Hhw9fUwpURIO5wMFUTEx8XEcSneTfUjVlbTz
9sOrV7shsxFNN2k9yXPQXlaw6EJLsQ1pAilRicIYO7/GVfk+oyyZ0svmRF2Z
avitZVNTlBOfeF//XtKAVhdQsLcPkv2nUuh1bw//d6+f7zBjmQoDcgsHyaNH
yaMZ/m/vMQbHP36SPNpPHk2Tx3vJowl+gs8c0DNT7O47ydei93dlUB/29vD/
9xjIg3gg8PYBTBj+eSxzxk9g2tubfaADCZj0fmkRLB6TLCyx7VhsIj0JIjH5
xT0wa7vfvWZhPLoWyU5VopsGwQh2OxZmv3PC2o5OpJ+EVsykLA5JnbztDd/2
cHqfmc6j1tlhwNKjAz/N0VGY5/7/v2cIV/rg8z22R4ARsQf+9dGXXmi+Lv62
kbZwcPSld5otkFG5vdX3Wss/8A6EEdxrLR+YhZTX77OWD2QhjxEhd7PKatPQ
vZb0gaxnOPWXvlplSof3C0e+feKx0MWjx89uUJkMx/5J+3p/7c8ffexHydPx
fUeAuwWz8lO497GVg39ELTx6goPEoU5wkF/XwpaDf6/V/OMP/ujth3ut5oNo
KWUK9zux0VLSMbvH60nXmT/xsgwOjpLqC4kDoUd/7x3o0ejejvb3/laWvcDq
Rv9nXYan921AdvBp12WYjpLH+zKj7S38H3wZ7rOaD+Kl5OP2YTr6W1eVpi0t
fPky2KugcDgqtLPn/d4XZGcLnCn+aND3s54p5tAPvx8dHO/3PvP+rr9oR0f/
PBcNRvDo8z22R0CnQ18f3VtalLNxwNLWiNZgb5qMn4gC87n/7XMTs7wC9VFs
OPdp5ujANlODKllMo3b+me4tjuA+m/PA7Ay/fq/NedDYGXwd1wD+P337YfxE
tTr9fzjrzW8a/99v9tPevn+0r6ODbX019tjoUXelkhDK3qD8iy9RjOjzDoqw
PxodHxweHh97WOMDw2D/wHv/dXc9buEPvff31xLldO0/al/Y/WQ0wrEfHka3
dbIn6txILuz/qpv61VfUt/BH39R7KorxWnbcHvh9NMLpvP1wePi52zPR3+Hp
Uev2tK/NSRGui6mvmi3GGbkXKR+Mw/DuZZYoq+vP899Ql2Ww/zS4rJ9pSlof
H/g8/6bnnn1F3SbDrA+f/G+3jMySx6Pk0eNOZn3vEeBB2/OvH37phdYEKHJH
jtvh76detwxrgaPZ//2jMa38A2OJB3FvNSFakqeqr9z35ztOao0sT6BzHNzb
dkXNBMXjvjaA1lC8LeDgIBlNk4P95ODrlqg9lN+zxfHe/hHn1XORrz8p2s7/
NqseUL/7yYX3G0EgAvL6fdb1Qdei/i622yICv2s0LSLwu8bSGsT9FNwOInBP
Yym30yYCN/enJQ+aN++exqv2UMSKRaz2Hx7K/be4tbd/wHm1gs5XnZUHEREw
pmiDJkTJMxS6UpuEw7zoxCgZrzGQkZAK8sJ6Ie8vKJEw1Jth2D7Qkrf9cVr1
b0a939MKNrL3dATNYIA/N9SpsvwTSD//IKtvlbX+4gTsQdoX99CT+7WSNBks
Vw2BtTiayHKM4JcRrsXjz979NoP95xE7/tn44z/IDO5zUh50HhNo5L4H5UHH
MZnB/e5315n/QjMRCf5nYEyRDhk+94XENeGV0ng08EU+pGKh9TytOSnyruwi
sGS9QT//C8bp5cgWhepfj2tJu/YVv6MgFMa/l8hgRxEsearx8Y08Pgwa0VRx
DBrmqkYVxYbom5OMcN+zDxRnrzHDFEIS13X7Q6zTeIT3RwfP0vFEf51ms8+9
sGs25KdQXhKjDAXGyudiGY53b5O6V9Tv95pX5r/6Daoneq831CJw77fI6meX
L2cY5TjpTqCIMXdkTNXrKE313gvYSLLBHbZWTNijt73GM297SQvy0A/k940i
2Fv4dEWemYAQ5XN9qCworco/0FU4O80J+28aU6VJYsDh2OOHaNFgF0aJqX5/
qG+ouTp9/sdcys/amn7PRcT4N/y8PasHCiwGNIsWzzEGjJI/zuTgkFgpuZVR
Pno2zeH54S4mixBMx8BEnNe3kzGF9tcD4XDfJpcYaIg5662Y/YSD9ncIf4nq
RflgU2pZloOKKgjSH6dPazHLKvNB8hRNPdNkyeEXR7cvo3uVVlV5l2B9U4Sq
KevV4Pzs8odkgsAtGqSpRTrh+VP63JdxkEhtjPpF5uPj0WVD/Ib+iSLM71KP
gmKCNZEB+fZDATgKu2xmPmOcsk9clzpIvhMNehT4zJqRInGhlHuuA4TRlxZo
z8UT1uBuwai+KxOPbq8IxZ9vce+ptHjGyQeYcTXFSuucB09pkTh0Wv6K0Cgt
hGvYAgKa9dBOnHJAMeYxkiWDV/q3TkxfkmUllVJCiu0cmlqn12E3sCkcFsG7
fFimlNZjIEjx9R8vry59eqF/88w/ndeTNWOjw8OcaaA5Ef7p59FDvtoAEqVw
TqKyvTQ4zo9aY4g9wrrQznQCLJhVMPkS/vLESD2IFEAJEPYGyN5xGqymeQjx
DFuD0KNKQf6/yq6tp20sCL/zKyy/ABJJA3TbvrBSFYoWaanYovbdSQx4N4mz
MeHSX9/zze3MOWZJlidAvhzPzJmbPd/XCua750w6/3rz4X1yNGH5CCQyHR5S
NsnXQDfUzGdTTDMQ0yBbdabR8Ih3m2ZG35i3SwPY+/zn9deiXhIbH2EbR6mx
S6PRQ74L3kYMFjw4jNcWWy35U8+SVRPgJIGtkJNsiKHkFRMPKV9lJi4r6xk6
PSKNjzmJZmDDhR/gdOd9q0MtVC1p+CszVxmkywwWJ/kPsCXFfaKwSAjEBRE3
JncxBegYugyQu0MuhcUqW8R6M5eP7+3b/jgndFsImK0Lh2nSNFTn7Qxoum67
bhAB5c0l86DfX98vx8VjF7Ly8fXhXrK4GaffS7M6w8tmLPxB0GQQmcfix5zP
c1PrruDZYRAFLdt5e/ciWmevxFzHzp5gRJOmC3t0AXaaaZcvhwMeEf3BIglX
W2Yhd3K0H9U8zQo905SDuPt8Lla4NV6OPuyZA0nxSyKpH1NdGDpHx8j6Mla2
53efv4JzWgbQsRaQOYDzLzfdJjwB7WfG9dCVUAh0kxaISIRrLOaTGY3MaiU0
i/hR77FVBL9ZQsMTMj3v9gXAY5La3Gwmy5q5cDwKqRaXmDAW/w+hEMBzWU/v
mSC1JMa98GfppA6ujOaBqcD8Tj2ggRB+YuJ85KfnKYZFuzb2WBWcRfRcjSbL
/eIAReqhUolpPMouYH43BONqPWP8Dud+RV3b5Ppe5cp0p5xq9qy+OFihWr+g
r0LGyI34VxoImx2aKCUnKSpQgwDLx+iseE6HcuXfP+nw0DaZOPor+XosdQIv
piHs+CgSnEvAq9eEwQCU4KjwKwqwMUgYPOUWSZ2mkmrgunTPMGNuEvqT7eJD
gsQA/7DR0OCAQqbKw5Y8q88OtcHMv6KNsLs1ZBGhzEmkieV19fx2QBg0HVMb
Rs+fW5XeOkU9yUKLoKSY09kqspPs6q/zp+jGTJRZzzznlcUTj0Dfe9yQumy6
/87hep5+RojVrWBnaRahNG0WiFIn6uIWb2zPdMDkAVdGuez5slMr0MiZAV/p
zfEEvufq7ru6X1d2HOeM9eux5uF+jUHzYERbNXWcaSqW70n1nhxF422Cok4V
IBPvSAgy4jOdVWbgizeUTO4arssg29Q6r6q/Ufa4GI/I2TXa1Cs5+jEY1Ti4
8/kYsLIxY43FBFJ1lagOABupiA7iCWmTHPdD2oiSFeCuRz5rkYm7/1uRjdIA
RDsquDpaRGvQBlmUqjgL5RhV8e9JdJ8VJfMBGPiUY9toV5hywwxmV1o4NIJM
tqUyaT6UTN3w9rOE36J7VEGTv9f2NMHhveby9Oi0rOz7KSC+2Ck88s4SclTf
cdDz5uulHPydnHtiOgQ6/RqAQepQtPnQI6TFyHWeih5xIbpSKo8jQNXetMTG
pcn+kX+feAQeMfqeEe4jlFfvwi4N0vd4CpzWjP/IzBAK2UipQ4Wns8tdFGVO
eT63WjJITxEIIpSwmICVW1JTs61HT5YlOOq2ip/1umU4xCehKLglzH9O88kr
A4nftLqqaQ96jUshVGBWE9AFDtSOSczLs5IgRqg1A/CTYGby8rZCa++MG6sY
ftb5cf4PoUqGJJlareYPbEzUtJSsRvuzYIfnl8T0cjmvh2JCJkwZVF3V3tVh
yD8ovMtlm1dq/SnspHQMnhGT9pRnhtJ92nS9Yk9Le7o8edf8ClQhEagZTDiZ
j97vrCuDWMU7Lq/ro+fZr7tlw0n0WVnuF44/ED4m5k1fwgZNqJfbu2a6i+0e
2x0Nii5o8D7EQ2q8caOSOjmT+uEJRmxulbZLEsmvqn/4EqWxyRbCJlsycd3q
IZHt0J8YrnMBEh6z97Ni9JadH1FCXWNs+7aovC/cVv/Rk2u0OFegUVCEBi0v
mp8RdYj/QThPAPuJEh4WBxHgOqbroPwTPxRbAN5Lh/MI4fpbjb7lvHKN5+XL
3bpevr1YYREjkGSiu/HQSoLAwEglA9eHtZUwFkMERmH7iyk2Ehs+JVw92HfD
UVwCmzUqYg/c9bjNLqSJc2vdmEgYpSAsw8TO2eqeGdoUZsB8Y+AIOxu9O5Yy
kFQtV1yooZkxFI+djjrTnxNuNuOKQzmJXgigZ22NKwXujpkGZYFcaslZ3WYC
0Kjwf8llsrUj0fVmM+wpVBsk/cgu7yyUnDFSnMFxDLoH4J9nnS1CzzkdnUBB
p6OPjni9WkyaUK+Bm3CXNZz0VYALhWRraVi8zIkVEXs8iIDuHsL4BoDD45S5
umhKO+xIcLRKwuH0qR8gQw21fkjtMjU0lKOEQ0Y4BSvuv6UQRN2flrs8nHq1
i+aZ3yaJTSLlI2QLvnD6woW58n6M9V66qp3uOLKQx8w+4jX3fgHuW7J7CoQB
AA==

-->
</rfc>