<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.8 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc docmapping="yes"?>

<rfc ipr="trust200902" docName="draft-pardue-quic-http-mcast-09" category="exp">

  <front>
    <title abbrev="HTTP over Mcast QUIC">Hypertext Transfer Protocol (HTTP) over multicast QUIC</title>

    <author initials="L." surname="Pardue" fullname="Lucas Pardue">
      <organization></organization>
      <address>
        <email>lucaspardue.24.7@gmail.com</email>
      </address>
    </author>
    <author initials="R." surname="Bradbury" fullname="Richard Bradbury">
      <organization>BBC Research &amp; Development</organization>
      <address>
        <email>richard.bradbury@bbc.co.uk</email>
      </address>
    </author>
    <author initials="S." surname="Hurst" fullname="Sam Hurst">
      <organization>BBC Research &amp; Development</organization>
      <address>
        <email>sam.hurst@bbc.co.uk</email>
      </address>
    </author>

    <date />

    
    
    

    <abstract>


<t>This document specifies a profile of the QUIC protocol and the HTTP/3 mapping that facilitates the transfer of HTTP resources over multicast IP using the QUIC transport as its framing and packetisation layer. Compatibility with the QUIC protocol’s syntax and semantics is maintained as far as practical and additional features are specified where this is not possible.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The means to bulk transfer resources over multicast IP <xref target="RFC1112"/> using HTTP semantics presents an opportunity to more efficiently deliver services at scale, while leveraging the wealth of existing HTTP-related standards, tools and applications. Audio-visual segmented media, in particular, would benefit from this mode of transmission.</t>

<t>The carriage of HTTP over multicast IP may be satisfied using existing technologies, for example the Real-time Transport Protocol (RTP) <xref target="RFC3550"/>, File Delivery over Unidirectional Transport (FLUTE) <xref target="RFC6726"/>, and NACK-Oriented Reliable Multicast (NORM) <xref target="RFC5740"/>. However, such protocols typically require the translation or encapsulation of HTTP. This introduces concerns for providers of services, such as defining the translation, additional workload, complication of workflows, manageability issues, versioning issues, and so on.</t>

<t>In contrast, this document describes a simpler and more direct expression of HTTP semantics over multicast IP. HTTP over multicast QUIC is a profile of the QUIC protocol <xref target="RFC9000"/> (<xref target="quic-profile"/>) and the HTTP/3 mapping <xref target="QUIC-HTTP"/> (<xref target="http-quic-profile"/>). This includes the repurposing of certain QUIC packet fields and changes to some protocol procedures (e.g. prohibition of the usage of certain frame types) which, in turn, change the behavioural expectations of endpoints. However, the profile purposely limits the scope of change in order to preserve maximum syntactic and semantic compatibility with conventional QUIC. For the reader’s convenience, the differences between this specification and conventional QUIC are summarised in <xref target="appendix-differences-summary-tables"/>.</t>

<t>This profile prohibits the transmission of QUIC packets from receiver to sender via multicast IP. The use of side-channel or out-of-band feedback mechanisms is not prohibited by this specification, but is out of scope and these are not considered further by the present document.</t>

<t>Experience indicates that a generally available multicast deployment is difficult to achieve on the Internet notwithstanding the improvements that IPv6 <xref target="RFC8200"/> makes in this area. There is evidence that discretely referenced multicast “islands” can more pragmatically be deployed. Discovery of such islands by receivers, as they become available, is typically difficult, however. To address the problem, this document describes an HTTP-based discovery mechanism that uses HTTP Alternative Services <xref target="RFC7838"/> to advertise the existence of multicast QUIC sessions (<xref target="session-advert"/>). This provides the means for multicast-capable endpoints to learn about and make use of them in an opportunistic and user-imperceptible manner. This mechanism results in a common HTTP application layer for both the discovery and delivery of services across unicast and multicast networks. This provides support for users and devices accessing services over a heterogeneous network. This is a departure from conventional multicast discovery technologies such as SDP <xref target="RFC8866"/> and SAP <xref target="RFC2974"/>.</t>

<t>The discovery mechanism also addresses some of the issues related to using QUIC over a unidirectional network association by replacing connection establishment aspects that depend on a bidirectional transport.</t>

<t>The present document includes a number of optional features. It is anticipated that further specifications will define interoperability profiles suited to particular application domains.</t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all captials, as shown here.</t>

<t>This document uses the Augmented BNF defined in <xref target="RFC5234"/> and updated by <xref target="RFC7405"/> along with the “#rule” extension defined in Section 7 of <xref target="RFC7230"/>. The rules below are defined in <xref target="RFC5234"/>, <xref target="RFC7230"/>, and <xref target="RFC7234"/>:</t>

<t><list style="symbols">
  <t>quoted-string = &lt;quoted-string, see <xref target="RFC7230"/>, Section 3.2.6&gt;</t>
  <t>token         = &lt;token, see <xref target="RFC7230"/>, Section 3.2.6&gt;</t>
  <t>uri-host      = &lt;uri-host, see <xref target="RFC7230"/>, Section 2.7&gt;</t>
</list></t>

</section>
<section anchor="definitions" title="Definitions">

<t>Definitions of terms that are used in this document:</t>

<t><list style="symbols">
  <t>endpoint: A host capable of being a participant in a multicast QUIC session.</t>
  <t>multicast QUIC session: A logical unidirectional flow of metadata and data over multicast IP, framed according to this specification. The lifetime of a session is independent of any endpoint.</t>
  <t>participant: A sender or receiver that is taking part in a multicast QUIC session.</t>
  <t>sender: A participant sending multicast traffic according to this specification.</t>
  <t>receiver: A participant receiving multicast traffic according to this specification.</t>
  <t>session: See multicast QUIC session.</t>
  <t>session ID: The identifier for a multicast QUIC session.</t>
  <t>session parameter: Characteristic of a multicast QUIC session.</t>
</list></t>

</section>
</section>
<section anchor="multicast-quic-sessions" title="Multicast QUIC Sessions">

<t>A QUIC connection <xref target="RFC9000"/> carried over bidirectional unicast is defined as a conversation between two QUIC endpoints that multiplexes several logical streams within a single encryption context. This is a one-to-one relationship. Furthermore, QUIC connections achieve decoupling from the underlying network (IP and port) by means of a set of Connection IDs, with each endpoint generating these IDs and using them to identify the direction of flow. Use of a consistent connection identifier allows QUIC connections to survive changes to the network connectivity. The establishment of a QUIC connection relies upon an up-front, in-band exchange (and possible negotiation) of cryptographic and transport parameters (conveyed in QUIC handshake messages).</t>

<t>The mapping of HTTP semantics over the QUIC transport protocol <xref target="QUIC-HTTP"/> facilitates the transfer of hypermedia over QUIC connections. The establishment of a HTTP/3 connection relies upon all the requirements stipulated for the transport, as well as communication of HTTP-specific settings (conveyed in HTTP/3 <spanx style="verb">SETTINGS</spanx> frames). Such parameters may be required or optional and may be used by either endpoint to control the characteristics of connection usage.</t>

<t>This concept of a connection does not suit the carriage of HTTP/3 over unidirectional network associations such as multicast IP. In fact, there is no requirement for either endpoint (multicast sender or receiver) to be in existence in order for the other to start or join this one-sided conversation. The term “connection” is misleading in this context; therefore we introduce an alternative term “multicast QUIC session” or simply “session”, which is defined as the logical entity describing the characteristics of the anticipated unidirectional flow of metadata and data. Such characteristics are expressed as “session parameters”, described in <xref target="intro-session-params"/>.  Advertisement of multicast QUIC sessions, specified in <xref target="session-advert"/>, allows for the senders and receivers to discover a session and to form multicast IP network associations that permit traffic flow.</t>

<section anchor="session-states" title="Session States">
<t>The lifecycle of a multicast QUIC session is decoupled from the lifecycle of any particular endpoint. Multicast receivers or senders that take part in a session are called participants. The state of a session is influenced by the actions of participants. The loose coupling of participants means that they are unlikely to have a consistent shared view of the current state of a session. There is no requirement for a participant to know the session state and the present document does not define a method to explicitly determine it. The definitions of session states provided below are intended to assist higher-level operational treatment of sessions:</t>

<t><list style="symbols">
  <t>Quiescent: the session has no participants and is ready to accept them.</t>
  <t>Half-established: the session has a participant.</t>
  <t>Fully-established: the session has a sender and at least one receiver participant.</t>
  <t>Finished: the session has ended, and there are no participants.</t>
</list></t>

<t>Permitted states transitions are shown in <xref target="session-statechart"/> below.</t>

<t>The transmission of QUIC packets is expected to occur only during the Half-Established and Fully-Established states.</t>

<figure title="Multicast QUIC session states" anchor="session-statechart"><artwork><![CDATA[
+-----------+         +------------------+        +-------------------+
|           |-------->|                  |------->|                   |
| Quiescent |         | Half-Established |        | Fully-Established |
|           |<--------|                  |<-------|                   |
+-----------+         +------------------+        +-------------------+
      |                        |
      |                        v
      |                   +----------+
      |                   |          |
      +------------------>| Finished |
                          |          |
                          +----------+
]]></artwork></figure>

<section anchor="session-establishment" title="Session Establishment">
<t>A session begins in the Quiescent state. A typical session establishment sequence would see the transition from Quiescent to Half-Established when a sender joins the session. The transition from Half-Established to Fully-Established occurs when at least one receiver joins the session.</t>

<t>It is equally valid for a receiver to join a session in the Quiescent state, triggering the transition to Half-Established. In this case, the transition to Fully-Established takes place only when a sender joins the session.</t>

</section>
<section anchor="session-termination" title="Session Termination">
<t>Participants MAY leave a session at any time. A session enters the Finished state when all participants have left it. Senders MAY signal their intent to leave using explicit session tear-down (<xref target="http-quic-session-tear-down"/>). Receivers can detect that a sender has left via idle timeout (<xref target="intro-session-idle-timeout"/>) and take that as a signal to leave, or receivers may leave as part of session migration (described in the next section).</t>

<t>In a typical case, a session that is in the Fully-Established state would be closed in two stages. In the first stage the sender sends explicit shutdown messages to the multicast group and subsequently stops transmitting packets. This causes the session to transition from Fully-Established to Half-Established. In the second stage, receivers that have received explicit shutdown messages leave the multicast group. Once all receivers have left the session it transitions from Half-Established to Finished.</t>

<t>The transition from Quiescent to Finished could also occur in response to out-of-band actions, for example the availability of a session being withdrawn without any participants having made use of it.</t>

</section>
<section anchor="session-migration" title="Session Migration">
<t>Endpoints MAY migrate between multicast QUIC sessions (for example, to make use of alternate session parameters that are preferred). Session migration requires participants to leave the current session and join the new session. These actions affect the state of the respective sessions as explained above.</t>

<t>The discovery of multicast QUIC sessions is described in <xref target="session-advert"/>.</t>

</section>
</section>
<section anchor="intro-session-params" title="Session Parameters">
<t>The characteristics of multicast QUIC sessions are expressed as session parameters, which cover cryptographic and transport parameters, HTTP-specific settings and multicast-specific configuration.</t>

<t>Session parameter exchange over IP multicast is difficult:</t>

<t><list style="symbols">
  <t>In-band exchanges are one-way, and so the client does not have the means to send session parameters.</t>
  <t>The lifecycle of any multicast sender is independent of the multicast receiver. It is therefore unlikely that all receivers will have joined a session in time to receive parameters sent at the start of a multicast session.</t>
</list></t>

<t>A range of strategies exists to mitigate these points. However, each has the possibility to add complexity to deployment and manageability, transmission overhead, or other such concerns. This document defines a solution that relies on the one-way announcement of session parameters in advance of session establishment. This is achieved using HTTP Alternative Services <xref target="RFC7838"/> and is explained in <xref target="session-advert"/>. Other advertisement solutions are not prohibited but are not explored in this document.</t>

<t>Session parameters MUST NOT change during the lifetime of a session. This restriction also applies to HTTP-level settings (see <xref target="http-connection-settings"/>).</t>

</section>
<section anchor="intro-session-id" title="Session Identification">

<t>This document defines an optional session identifier used to identify a session. This “Session ID” affords independence from multicast IP, creating the possibility for a session to span multiple multicast groups, or to migrate a session to a different multicast group. Assignment of Session ID is considered out of this document’s scope.</t>

<t>The Session ID is carried in the Destination Connection ID field of the QUIC packet (see <xref target="quic-connection-id"/>). Source Connection IDs are not used.</t>

<t>The maximum size of a Session ID is 160 bits. The size of the Destination Connection ID field used to convey the Session ID SHALL be the smallest number of full bytes required to represent the full Session ID value advertised in the <spanx style="verb">session-id</spanx> session parameter (<xref target="param-session-id"/>). If no <spanx style="verb">session-id</spanx> parameter is advertised, then this session has a zero-length session ID, and the Destination Connection ID field SHALL be omitted from all QUIC packets related to the session.</t>

<t>A multicast sender participating in a session with an advertised <spanx style="verb">session-id</spanx> session parameter MUST send QUIC packets with a matching Session ID. Conversely, a multicast sender participating in a session without an advertised <spanx style="verb">session-id</spanx> session parameter MUST NOT send QUIC packets with a non-zero-length Destination Connection ID field.</t>

<t>A multicast receiver participating in a session with an advertised <spanx style="verb">session-id</spanx> session parameter MUST validate that the Session ID of received QUIC packets matches that advertised in the session parameters (<xref target="param-session-id"/>) before any HTTP-level processing is done. In the case of validation failure, the receiver SHOULD ignore the packet in order to protect itself from denial-of-service attacks.</t>

</section>
<section anchor="intro-session-security" title="Session Security">

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> Security handshake (as described in WG documents) is in flux. This section will track developments and will be updated accordingly.</t>
</list></t>

<t>The QUIC cryptographic handshake (<xref target="RFC9000"/> and <xref target="RFC9001"/>) sets out methods to achieve the goals of authenticated key exchange and QUIC packet protection between two endpoints forming a QUIC connection. The design facilitates low-latency connection; 1-RTT or 0-RTT. This specification replaces the in-band security handshake, achieving similar goals through the use of session parameters described in <xref target="intro-security-params"/>.</t>

<t>Integrity and authenticity concerns are addressed in <xref target="security-integrity"/> and <xref target="security-authenticity"/> respectively. In order to protect themselves from attack vectors, endpoints SHOULD NOT participate in sessions for which they cannot establish reasonable confidence over the cipher suite or key in use for that session. Participants MAY leave any session that fails to successfully match anticipated security characteristics.</t>

</section>
</section>
<section anchor="session-advert" title="Session Advertisement">

<t>In this specification, connection negotiation is replaced with a session advertisement mechanism based on HTTP Alternative Services (Alt-Svc) <xref target="RFC7838"/>. This document specifies how the parameters of a multicast QUIC session are expressed as Alt-Svc parameters. The following sections provide a high-level view of these; further details are provided in <xref target="session-param-advert"/>, with examples provided in <xref target="appendix-session-advertisement"/>. QUIC connection parameters not defined as, or related to, Alt-Svc parameters are not used.</t>

<t>The definition of a session (including the session ID and its parameters) is not the responsibility of any endpoint. Rather, endpoints SHOULD use session advertisements to determine if they are capable of participating in a given session. This document does not specify which party is responsible for defining and/or advertising multicast QUIC sessions.</t>

<t>Endpoints SHOULD NOT become participants in sessions where the advertisement requirements set out in the present document are unfulfilled.</t>

<t>The freshness of Alt-Svc multicast QUIC session advertisements is as described in section 2.2 of <xref target="RFC7838"/>.</t>

<t>It is RECOMMENDED that session advertisements are carried over a secure transport (such as HTTPS) which can guarantee the authenticity and integrity of the Alt-Svc information. This addresses some of the concerns around the protection of session establishment described in <xref target="security-cons-disc"/>.</t>

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> We invite review comments on mandating the use of a secure transport for advertising sessions.</t>
</list></t>

<t>Senders MAY also advertise the availability of alternative sessions by carrying Alt-Svc in a multicast QUIC session.</t>

<section anchor="intro-security-params" title="Security Context">

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> Security handshake (as described in WG documents) is in flux. This section will track developments and will be updated accordingly.</t>
</list></t>

<t>This specification replaces the in-band security handshake. The session parameters “cipher suite”, “key” and “iv” (described below) allow for the establishment of a security context. In order to protect themselves, endpoints SHOULD NOT participate in sessions for which they cannot establish reasonable confidence over the cipher suite, key, or IV in use for that session. Endpoints SHOULD leave any sessions which fail to successfully match anticipated security characteristics.</t>

<section anchor="cipher-suite" title="Cipher Suite">
<t>Cipher suite negotiation is replaced with a “cipher suite” session parameter, which is advertised as the Alt-Svc parameter <spanx style="verb">cipher-suite</spanx> (<xref target="param-cs"/>).</t>

<t>The Alt-Svc “cipher-suite” parameter is OPTIONAL. If present, this parameter MUST contain only one value that corresponds to an entry in the TLS Cipher Suite Registry (see http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4). Session advertisements that omit this parameter imply that the session is operating with cipher suite 0x00,0x00 (NULL_WITH_NULL_NULL).</t>

</section>
<section anchor="key-exchange" title="Key Exchange">
<t>Key exchange is replaced with a “key” session parameter, which is advertised as the Alt-Svc parameter <spanx style="verb">key</spanx> (<xref target="param-key"/>). The parameter carries a variable-length hex-encoded key for use with the session cipher suite.</t>

<t>The Alt-Svc “key” parameter is OPTIONAL. Session advertisements that omit this parameter imply that the key may be available via an out-of-band method not described in this document.</t>

</section>
<section anchor="initialization-vector" title="Initialization Vector">
<t>Initialization Vector (IV) exchange is replaced with an “iv” session parameter, which is advertised as the Alt-Svc parameter <spanx style="verb">iv</spanx> (<xref target="param-iv"/>). The parameter carries a variable-length hex-encoded IV for use with the session cipher suite and key.</t>

<t>The Alt-Svc “iv” parameter is OPTIONAL. Session advertisements that omit this parameter imply that the IV may be available via an out-of-band method not described in this document.</t>

</section>
</section>
<section anchor="session-identification" title="Session Identification">
<t><xref target="RFC9000"/> specifies how the QUIC connection identifiers are used, in particular the independent selection of these identifiers by each endpoint for its peer. In a unidirectional multicast environment, there is no meaningful way for an endpoint to generate a connection identifier for its peer to use. This document defines a “session identifier” session parameter, which is advertised as the Alt-Svc parameter “session-id” (<xref target="param-session-id"/>). The requirements for the usage of session identifiers have already been described in <xref target="intro-session-id"/>.</t>

<t>The Alt-Svc “session-id” parameter is optional. Session advertisements MAY contain at most one instance of a “session-id” parameter. Session advertisements that identify the same Any Source Multicast group {G} or Source Specific Multicast group {S,G} indicate that multiple sessions are multiplexed in the same multicast group and each such advertisement must carry a unique “session-id”.</t>

</section>
<section anchor="intro-session-idle-timeout" title="Session Idle Timeout">
<t>Conventional QUIC connections may be implicitly terminated following a period of idleness (lack of network activity). The optional QUIC TransportParameter <spanx style="verb">max_idle_timeout</spanx> provides a means for endpoints to specify the timeout period. This document defines a “session idle timeout” session parameter, which is advertised as the Alt-Svc parameter “session-idle-timeout” (<xref target="param-session-idle-timeout"/>). This session parameter mimics the behaviour of <spanx style="verb">max_idle_timeout</spanx>, providing a means for multicast QUIC sessions to define their own idle timeout periods.</t>

<t>Session idle timeout may be prevented by keep-alive strategies <xref target="session-keep-alive"/>.</t>

<t>The Alt-Svc “session-idle-timeout” parameter is optional. Session advertisements MAY contain zero or more instances of this parameter. If it is repeated, the first occurrence MUST be used and subsequent occurrences MUST be ignored. Session advertisements that omit the “session-idle-timeout” parameter, or set it to zero never time out.</t>

<t>Receiving participants SHOULD leave multicast QUIC sessions when the session idle timeout period has elapsed (<xref target="quic-connection-shutdown"/>). Leaving participants MUST use the silent close method, in which no QUIC <spanx style="verb">CONNECTION_CLOSE</spanx> frame is sent.</t>

</section>
<section anchor="intro-peak-flow-rate" title="Session Peak Flow Rate">
<t><xref target="RFC9000"/> specifies a credit-based stream- and connection-level flow control scheme which prevents a fast sender from overwhelming a slow receiver at the stream level, as well as an aggregate level of all streams. Window size connection parameters are exchanged on connection establishment using the required QUIC TransportParameters <spanx style="verb">initial_max_data</spanx>, <spanx style="verb">initial_max_stream_data_bidi_local</spanx>, <spanx style="verb">initial_max_stream_data_bidi_remote</spanx> and <spanx style="verb">initial_max_stream_data_uni</spanx>. In a unidirectional multicast environment, such a scheme is infeasible.</t>

<t>This document defines a “peak flow rate” session parameter, expressed in units of bits per second, which is advertised as the Alt-Svc parameter “peak-flow-rate” (<xref target="param-flow-rate"/>). This completely replaces the transport parameters listed above, instead indicating the maximum bit rate of QUIC payloads transmitted on all multicast groups comprising the session. It applies at the aggregate level, and is not specific to any single stream.</t>

<t>The Alt-Svc “peak-flow-rate” parameter is OPTIONAL. If the parameter is repeated the first occurrence MUST be used and subsequent occurrences MUST be ignored. Session advertisements that omit the parameter imply that the flow rate is unlimited.</t>

<t>A multicast sender SHOULD NOT cause the advertised peak flow rate of a session to be exceeded. A receiver MAY leave any session where the advertised peak flow rate is exceeded.</t>

</section>
<section anchor="intro-resource-concurrency" title="Resource Concurrency">
<t><xref target="RFC9000"/> considers concurrency in terms of the number of active incoming streams, which is varied by the receiving endpoint adjusting the maximum Stream ID. The initial value of maximum Stream ID is controlled by the relevant required QUIC TransportParameters <spanx style="verb">initial_max_streams_bidi</spanx> and <spanx style="verb">initial_max_streams_uni</spanx>. They are increased during the lifetime of a QUIC connection by the QUIC <spanx style="verb">MAX_STREAMS</spanx> frame. In a unidirectional multicast environment, there is no way for a receiver to specify an initial limit nor to increase it. Therefore in multicast QUIC, the maximum Stream ID (initial and always) is 2^62. This mechanism is not used to manage concurrency in multicast QUIC.</t>

<t>Due to the profiling of maximum Stream ID, there is no role for the QUIC <spanx style="verb">STREAMS_BLOCKED</spanx> frame and it is prohibited. Participants MUST NOT send this frame type. Reception of this frame type MUST be handled as described in <xref target="prohibited-quic-frames"/>.</t>

<t>This document specifies a “maximum concurrent resources” session parameter, which is advertised as the Alt-Svc parameter “max-concurrent-resources” (<xref target="param-max-concurrent-resources"/>). This parameter replaces <spanx style="verb">initial_max_stream_id_bidi</spanx> and <spanx style="verb">initial_max_stream_id_uni</spanx>. It advertises the maximum number of concurrent active resources generated by a sender in a given multicast QUIC session.</t>

<t>The Alt-Svc “max-concurrent-resources” parameter is OPTIONAL. If the parameter is repeated the first occurrence MUST be used and subsequent occurrences MUST be ignored. Session advertisements that omit the parameter imply that the maximum concurrency is unlimited.</t>

<t>A multicast sender participating in a session MUST NOT cause the advertised “max-concurrent-resources” to be exceeded. A receiver MAY leave any session where the advertised limit is exceeded, in order to protect itself from denial-of-service attacks.</t>

</section>
<section anchor="intro-extensions" title="Additional TransportParameter Considerations">

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> This section will consider TransportParameters that have not already been addressed, as required. It will track developments and issues that may arise.</t>
</list></t>

<t>Section 19.21 of <xref target="RFC9000"/> defines a mechanism for endpoints to show willingness to receive one or more extension frame types. It is not possible for multicast QUIC receivers to signal this information to senders.</t>

<t>This document defines an “extensions” session parameter, which is advertised as the Alt-Svc parameter “extensions” <xref target="param-extensions"/> and replaces the transport parameter exchange detailed above. The Alt-Svc “extensions” parameter is optional. Session advertisements MAY contain zero or more instances of this parameter. The parameter lists transport parameter values present in the QUIC Transport Parameter Registry as specified in Section 22.3 of <xref target="RFC9000"/>.</t>

<t>Only transport parameters which expressly reference Multicast QUIC are considered valid extension parameters.</t>

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> The authors welcome suggestions for how to map these extension types more cleanly into this document.</t>
</list></t>

<t>Participants SHOULD NOT join sessions advertising extensions that they do not support, as QUIC frames are not self-describing.</t>

</section>
<section anchor="intro-digest-algorithm" title="Digest Algorithm">
<t>A method to provide content integrity is described in <xref target="security-integrity"/>. This specifies the means to convey a value computed by a particular digest algorithm. The identity of the selected algorithm is also indicated. Valid digest algorithms are collected in the IANA HTTP Digest Algorithm Values registry (http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1).</t>

<t>This document specifies a “digest algorithm” session parameter, which is advertised as the Alt-Svc parameter “digest-algorithm” (<xref target="param-digest-algorithm"/>).</t>

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> <xref target="security-integrity"/> contains an author’s note on the potential for content integrity to become mandatory. This section will be updated in line with the outcome of that decision.</t>
</list></t>

<t>The Alt-Svc “digest-algorithm” parameter is OPTIONAL. Repetition of the “digest algorithm” parameter in a single advertisement describes an algorithm set that MAY be used across the session. Session advertisements that omit the Alt-Svc parameter <spanx style="verb">digest-algorithm</spanx> imply that either:</t>

<t><list style="symbols">
  <t>the session does not use the content integrity mechanism, or</t>
  <t>the algorithm set is unrestricted, i.e. a sender may vary the algorithm as it so chooses. This may lead to undesirable results if receivers do not support a chosen algorithm.</t>
</list></t>

<t>Advertising the algorithm set for a session gives receivers the opportunity to selectively join sessions where the algorithms are known to be supported. This may help to mitigate latency issues in the receiver resulting from joining a session only to discover some of its parameters are not supported.</t>

<t>A multicast sender participating in a session MUST NOT use algorithms outside the signalled digest algorithm set. A receiver MAY leave any session where an algorithm outside the digest algorithm set is used.</t>

</section>
<section anchor="intro-signature-algorithm" title="Signature Algorithm">
<t>A method to provide content authenticity is described in <xref target="security-authenticity"/>. This specifies the means to convey a value computed by a particular signature algorithm. The identity of the selected algorithm is also indicated. Valid signature algorithms are collected in the IANA Signature Algorithms registry (http://www.iana.org/assignments/signature-algorithms).</t>

<t>This document specifies a “signature algorithm” session parameter, which is advertised as the Alt-Svc parameter <spanx style="verb">signature-algorithm</spanx> (<xref target="param-signature-algorithm"/>).</t>

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> <xref target="security-authenticity"/> contains an author’s note on the potential for content authenticity to become mandatory. This section will be updated in line with the outcome of that decision.</t>
</list></t>

<t>The Alt-Svc “signature-algorithm” parameter is OPTIONAL. Repetition of the “signature algorithm” parameter in a single advertisement describes an algorithm set that MAY be used across the session. Session advertisements that omit the Alt-Svc parameter <spanx style="verb">signature-algorithm</spanx> imply that either:</t>

<t><list style="symbols">
  <t>the session does not use the content authenticity mechanism, or</t>
  <t>the algorithm set is unrestricted i.e. a sender may vary the algorithm as it so chooses. This may lead to undesirable results if receivers do not support a chosen algorithm.</t>
</list></t>

<t>Advertising the algorithm set for a session gives receivers the opportunity to selectively join sessions where the algorithms are known to be supported. This may help to mitigate latency issues in the receiver resulting from joining a session only to discover some of its parameters are not supported.</t>

<t>A multicast sender participating in a session MUST NOT use algorithms outside the signalled signature algorithm set. A receiver MAY leave any session where an algorithm outside the signature algorithm set is used.</t>

</section>
</section>
<section anchor="quic-profile" title="QUIC Profile">

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> The QUIC transport document is subject to change. This section is based on our best understanding of draft-ietf-quic-transport-29. The authors will track developments and will update this section accordingly.</t>
</list></t>

<t>The profile of <xref target="RFC9000"/> is presented in this section. In order to preserve compatibility with conventional QUIC, the specification works with a limited scope of change. However, the nature of unidirectional multicast communications means that some protocol procedures or behaviours need to be modified.</t>

<t>Section 5.3 of <xref target="RFC9000"/> defines a set of required actions that a QUIC server and QUIC client must be able to perform. Due to the limitations of this profile, all of the requirements in Section 5.3 of <xref target="RFC9000"/> are removed except for:</t>

<t><list style="symbols">
  <t>Configuring the minimum and total number of permitted streams of each type is described in <xref target="intro-resource-concurrency"/>.</t>
  <t>Multicast QUIC senders may still send <spanx style="verb">PING</spanx> frames to stop a session from expiring as described in <xref target="session-keep-alive"/>.</t>
</list></t>

<section anchor="packet-size" title="Packet Size">
<t>The means for determining an appropriate size for QUIC packets are described in Section 14 of <xref target="RFC9000"/>. Implementations of this specification SHOULD bear in mind that the Path Maximum Transmission Unit (PMTU) may be affected by multicast IP technologies such as Automatic Multicast Tunneling (AMT) <xref target="RFC7450"/>. Additionally, consideration should be given toward the applicability of maximum transmission unit discovery methods (such as PLPMTUD <xref target="RFC4821"/> and PMTUD <xref target="RFC1191"/>) to multicast IP.</t>

</section>
<section anchor="quic-packet-format" title="Packet Format">
<t>Endpoints implementing this specification MUST only send QUIC packets with the short header form. As short header packets do not include a length, senders MUST NOT attempt to coalesce any QUIC packets in the same UDP datagram. Therefore, all UDP datagrams sent by senders conforming to this profile contain exactly one QUIC packet.</t>

<section anchor="packet-numbers" title="Packet Numbers">
<t>All packets for this profile SHALL be numbered in the application data packet number space. The initial and handshake packet number spaces are not used by this profile, as the handshake is replaced by an out-of-band mechanism (see <xref target="intro-session-security"/>).</t>

<t>The encoding of packet numbers in QUIC packets is described in Section 17.1 of <xref target="RFC9000"/>. Senders must always use the same number of bytes to represent the packet number for all packets sent to a session. Because a receiver may join a session after the sender has already sent several packets, it MUST NOT assume that the first packet number will be 0.</t>

</section>
<section anchor="spin-bit" title="Spin Bit">
<t><xref target="RFC9000"/> specifies a bit in the 1-RTT packet header as the latency spin bit that may be used to measure network round trip latency between a client and a server. This mechanism is not usable in a unidirectional multicast packet flow. Senders SHALL set the spin bit to zero in all packets. Receivers SHOULD ignore the spin bit.</t>

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> The authors welcome suggestions for the use of the spin bit in a multicast context.</t>
</list></t>

</section>
</section>
<section anchor="quic-connection-id" title="Connection Identifier">
<t>The Destination Connection ID field MUST be non-zero-length in every QUIC packet if the session was advertised with a <spanx style="verb">session-id</spanx> session parameter (<xref target="param-session-id"/>). If the multicast QUIC session advertisement does not carry a “session identifier” session parameter, then the Destination Connection ID MUST be zero-length in any QUIC packet for that session. In the case where multiple sessions are multiplexed on the same 5-tuple network association, the Destination Connection ID field MUST be non-zero-length in every QUIC packet and must be distinct for each session.</t>

</section>
<section anchor="quic-stream-id" title="Stream Identifier">
<t>The maximum Stream ID of a multicast QUIC session is 2^62, as explained in <xref target="intro-resource-concurrency"/>. With the exception of the first client-initiated request Stream ID, which is reserved as described in <xref target="server-push"/>, all Stream ID values SHALL be of the server-initiated unidirectional stream type.</t>

</section>
<section anchor="flow-control" title="Flow Control">
<t>Conventional QUIC provides stream- and connection-level flow control, and endpoints manage this by sending QUIC <spanx style="verb">MAX_DATA</spanx> or <spanx style="verb">MAX_STREAM_DATA</spanx> frames as required. When a sender is blocked from sending flow-controlled frames, it sends an informational QUIC <spanx style="verb">DATA_BLOCKED</spanx> or <spanx style="verb">STREAM_DATA_BLOCKED</spanx> frame.</t>

<t>In a unidirectional environment, the sender never has a receive window and the receiver cannot send in-band updates. Therefore, the management of flow-control windows and transmission of blockage information is not supported by this profile. The QUIC <spanx style="verb">MAX_DATA</spanx>, <spanx style="verb">MAX_STREAM_DATA</spanx>, <spanx style="verb">DATA_BLOCKED</spanx> and <spanx style="verb">STREAM_DATA_BLOCKED</spanx> frames are prohibited by this profile. Participants MUST NOT send these frame types. Reception of these frame types MUST be handled as described in <xref target="prohibited-quic-frames"/>.</t>

</section>
<section anchor="stream-termination" title="Stream Termination">
<t>A sender MAY prematurely terminate the transmission on any unreserved QUIC Stream ID by setting the <spanx style="verb">FIN</spanx> bit of a QUIC <spanx style="verb">STREAM</spanx> frame, or by sending a QUIC <spanx style="verb">RESET_STREAM</spanx> frame (as specified in <xref target="RFC9000"/> and <xref target="QUIC-HTTP"/>).</t>

<t>Receiving participants MUST NOT make any attempt to send QUIC <spanx style="verb">RESET_STREAM</spanx> frames to the multicast group.</t>

</section>
<section anchor="quic-connection-shutdown" title="Connection Shutdown">
<t>Explicit shutdown of a multicast QUIC session using QUIC methods is not supported by this profile.</t>

<t>The QUIC <spanx style="verb">CONNECTION_CLOSE</spanx> frames and the Stateless Reset packet are prohibited. Participants MUST NOT send these and reception MUST be handled as described in <xref target="prohibited-quic-frames"/>.</t>

<t>Explicit session tear-down using HTTP semantics is allowed, as described in <xref target="http-quic-session-tear-down"/>.</t>

<t>Implicit shutdown by means of silent close is also supported, as described in <xref target="intro-session-idle-timeout"/>.</t>

</section>
<section anchor="connection-migration" title="Connection Migration">
<t><xref target="RFC9000"/> has a connection migration feature that allows a connection to survive changes to endpoint addresses. This profile does not currently support connection migration, and as such the QUIC <spanx style="verb">NEW_CONNECTION_ID</spanx> and <spanx style="verb">RETIRE_CONNECTION_ID</spanx> frames are prohibited. Similarly, the QUIC <spanx style="verb">PATH_CHALLENGE</spanx> and <spanx style="verb">PATH_RESPONSE</spanx> frames are also prohibited, but additionally because they require bidirectional capability that this profile does not provide.</t>

<t>Endpoints participating in a session conforming to this profile MUST only use a single session ID for the duration of the session, and as such there is no mapping for the <spanx style="verb">active_connection_id_limit</spanx> transport parameter specified in section 5.1.1 of <xref target="RFC9000"/> in this profile.</t>

<t><list style='empty'>
  <t><spanx style="strong">Author’s Note</spanx>: Seamless migration from one multicast QUIC session to another is described in Section 2.1.3.</t>
</list></t>

</section>
<section anchor="ecn" title="Explicit Congestion Notification">
<t><xref target="RFC9000"/> specifies that clients may use Explicit Congestion Notification (ECN) <xref target="RFC3168"/>. ECN allows receivers to inform senders of impending congestion before packets are dropped, and the sender may then reduce its transmission rate. As ECN requires bidirectional communication for the receiver to inform the sender of the congestion, the use of ECN for this profile is prohibited.</t>

<t><list style='empty'>
  <t><spanx style="strong">Author’s Note</spanx>: It is the responsibility of a receiver to determine whether network conditions permit the uncongested reception of a given session based on the advertised <spanx style="verb">peak-flow-rate</spanx> parameter.</t>
</list></t>

</section>
<section anchor="session-keep-alive" title="Session Keep-alive">
<t>The flow of traffic in a multicast QUIC session is driven by a sender. There may be periods where the sender has no application data to send for a period longer than the session idle timeout. This profile repurposes the QUIC <spanx style="verb">PING</spanx> frame to act as a unidirectional keep-alive message that may be sent in order to inform receivers that the session should remain in the Fully-established state. <xref target="RFC9000"/> contains guidance on the sending frequency of QUIC <spanx style="verb">PING</spanx> frames.</t>

<t>Senders MAY send a QUIC <spanx style="verb">PING</spanx> frame at any time in order to inform receivers that the session traffic flow has not fallen idle. This frame MUST NOT be acknowledged. Indeed, QUIC <spanx style="verb">ACK</spanx> frames are prohibited by this profile (<xref target="loss-detection"/>).</t>

<t>Receiving participants MUST NOT make any attempt to send QUIC <spanx style="verb">PING</spanx> frames.</t>

</section>
<section anchor="loss-detection" title="Loss Detection and Recovery">
<t>Receivers implementing this profile MUST NOT make any attempt to acknowledge the reception of QUIC packets. The QUIC <spanx style="verb">ACK</spanx> frame is prohibited for both senders and receivers. Reception of this frame MUST be handled as described in <xref target="prohibited-quic-frames"/>.</t>

<t><xref target="loss-recovery"/> specifies alternative strategies for loss recovery.</t>

</section>
<section anchor="prohibited-quic-frames" title="Prohibited QUIC Frames and Packets">
<t>The following QUIC packets MUST NOT be transmitted by participants: Any packets with a long header (Initial, 0-RTT Protected, Handshake, Retry), Version Negotiation, Stateless Reset.</t>

<t>The following QUIC frames MUST NOT be transmitted by participants: <spanx style="verb">ACK</spanx>, <spanx style="verb">CONNECTION_CLOSE</spanx>, <spanx style="verb">CRYPTO</spanx>, <spanx style="verb">DATA_BLOCKED</spanx>, <spanx style="verb">HANDSHAKE_DONE</spanx>, <spanx style="verb">MAX_DATA</spanx>, <spanx style="verb">MAX_STREAM_DATA</spanx>, <spanx style="verb">MAX_STREAMS</spanx>, <spanx style="verb">NEW_CONNECTION_ID</spanx>, <spanx style="verb">NEW_TOKEN</spanx>, <spanx style="verb">PATH_CHALLENGE</spanx>, <spanx style="verb">PATH_RESPONSE</spanx>, <spanx style="verb">RETIRE_CONNECTION_ID</spanx>, <spanx style="verb">STOP_SENDING</spanx>, <spanx style="verb">STREAM_DATA_BLOCKED</spanx>, <spanx style="verb">STREAMS_BLOCKED</spanx>.</t>

<t>In addition, any QUIC extension frames not advertised in the session advertisement <xref target="intro-extensions"/> MUST NOT be transmitted by participants.</t>

<t>The following QUIC frames MUST NOT be transmitted by receivers: <spanx style="verb">PING</spanx>, <spanx style="verb">RESET_STREAM</spanx>.</t>

<t>Reception of a prohibited or non-advertised QUIC frame or packet is a protocol error. Receivers MUST ignore all prohibited QUIC frames and packets.</t>

</section>
</section>
<section anchor="http-quic-profile" title="HTTP/3 Profile">

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> The HTTP/3 mapping document is subject to change. This section is based on our best understanding of draft-ietf-quic-http-29. The authors will track developments and will update this section accordingly.</t>
</list></t>

<t>HTTP over multicast QUIC depends on HTTP server push, as described in Section 4.4 of <xref target="QUIC-HTTP"/>. <xref target="server-push"/> below applies an additional constraint on the use of server push. A multicast sender participating in a session pushes resources as a series of QUIC <spanx style="verb">STREAM</spanx> frames carrying HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx>, <spanx style="verb">HEADERS</spanx> and <spanx style="verb">DATA</spanx> frames. Examples of this are provided in <xref target="appendix-resource-transfer"/>. Senders MUST comply with the requirements of the session parameters, as described earlier in <xref target="session-advert"/>.</t>

<t>The profile of HTTP/3 specified in this section places additional constraints on the use of metadata compression (<xref target="metadata-compression"/>).</t>

<section anchor="http-connection-settings" title="HTTP Connection Settings">

<t>The HTTP/3 <spanx style="verb">SETTINGS</spanx> frame is prohibited by this profile. Participants MUST NOT make any attempt to send this frame type. Reception of this frame MUST be handled as described in <xref target="prohibited-hq-frames"/>.</t>

</section>
<section anchor="server-push" title="Server Push">
<t>Server push is, by default, disabled for HTTP/3 connections. A conventional HTTP/3 client enables and manages server push by controlling the maximum Push ID (<xref target="QUIC-HTTP"/>, Section 7.2.7), achieved by sending the HTTP/3 <spanx style="verb">MAX_PUSH_ID</spanx> frame.</t>

<t>This profile mandates the use of server push, and specifies no means to disable it. The maximum Push ID for multicast QUIC sessions (initial and always) is 2^62. Values of Push ID SHALL be allocated in accordance with <xref target="QUIC-HTTP"/>.</t>

<t>Server push concurrency in multicast QUIC is described in <xref target="intro-resource-concurrency"/>. There is no role for the HTTP/3 <spanx style="verb">MAX_PUSH_ID</spanx> frame and it is prohibited. Participants MUST NOT send this frame type. Reception of this frame type MUST be handled as described in <xref target="prohibited-hq-frames"/>.</t>

<t>For this profile, the Stream Type for any new server-initiated unidirectional stream MUST be Server Push (<spanx style="verb">0x01</spanx>).</t>

<t>The HTTP/3 <spanx style="verb">CANCEL_PUSH</spanx> frame MAY be used by sending participants to abort sending a response for the identified server push. Usage of this frame SHALL follow the guidance for servers in <xref target="QUIC-HTTP"/>.</t>

<t>Receiving participants MUST NOT make any attempt to send HTTP/3 <spanx style="verb">CANCEL_PUSH</spanx> frames to the multicast group.</t>

<t>Receiving participants SHOULD ignore all frames on server-initiated unidirectional streams for which the packet containing the Push ID has not been received. Receiving participants SHOULD ignore all frames on server-initiated unidirectional streams carrying a Push ID that was not previously promised to the receiver.</t>

<t>Conventionally, pushed responses are associated with an explicit request from a client. This is not possible when using a unidirectional transport such as multicast IP. This profile reserves the first client-initiated, bidirectional QUIC stream. HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx> frames MUST be sent on this reserved Stream ID.</t>

</section>
<section anchor="metadata-compression" title="Metadata Compression">
<t>The compression of HTTP header fields is considered in QPACK <xref target="QUIC-QPACK"/>, which describes two methods for the compression of HTTP header fields: indexing (via static or dynamic tables) and Huffman encoding.</t>

<t>A multicast QUIC session, as described in the present document, does not provide the assurances (receiver participation, transport reliability) required to sufficiently maintain the dynamic decoding context. Therefore, this document requires that endpoints SHALL NOT use dynamic table indexing. It is RECOMMENDED that endpoints use static table indexing and/or Huffman encoding in order to benefit from the remaining compression methods available.</t>

</section>
<section anchor="http-quic-session-tear-down" title="Session Tear-down">
<t>A multicast QUIC session MAY be explicitly torn down by means of the <spanx style="verb">Connection: close</spanx> HTTP header described in section 6.6 of <xref target="RFC7230"/>. A sender intending to leave the session SHOULD include the <spanx style="verb">Connection: close</spanx> header in its response metadata. A sender SHOULD transmit all outstanding frames related to remaining request/response exchanges before ending transmission to the multicast group. A receiver SHOULD continue to receive and process frames until all outstanding request/response exchanges are complete.</t>

<t>The HTTP/3 <spanx style="verb">GOAWAY</spanx> frame is prohibited. Participants MUST NOT send this and reception MUST be handled as described in <xref target="prohibited-hq-frames"/>.</t>

</section>
<section anchor="http-quic-packet-loss" title="Effects of Packet Loss">
<t>Since multicast QUIC is an inherently unreliable delivery mechanism, portions of HTTP messages sent by the sender may not be received by the receiver. Conventional HTTP/3 frames assume reliable, in-order delivery by the underlying QUIC stream. HTTP/3 frames do not therefore carry any information indicating their position within the stream, because this information is instead carried in the QUIC <spanx style="verb">STREAM</spanx> frame header.</t>

<t>In multicast QUIC, packet loss leaves gaps in the flow of a stream, and therefore gaps in the HTTP/3 frame(s) that are carried on that stream.</t>

<t><list style="numbers">
  <t>Loss of an HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx> frame renders the reception of an entire stream impossible, since the receiver ignores the new push stream that has not been promised as described in <xref target="server-push"/>.</t>
  <t>Loss of a QUIC packet comprising all or part of an HTTP/3 <spanx style="verb">HEADERS</spanx> frame will likely prevent the QPACK decoder from successfully parsing the received metadata, leaving the receiver unable to make use of the affected HTTP representation.</t>
  <t>Loss of a QUIC packet containing an HTTP/3 <spanx style="verb">DATA</spanx> frame header leaves a receiver unsure where to look for the start of the next HTTP/3 frame on the same stream. In the unlikely event that the receiver manages to resynchronise to the start of a subsequent HTTP/3 <spanx style="verb">DATA</spanx> frame, the position of the payload in the HTTP representation data is unknown because it is not explicitly signalled in the <spanx style="verb">DATA</spanx> frame header. The Offset field in the QUIC <spanx style="verb">STREAM</spanx> header describes the offset within the stream, but it is impossible for the receiver to know the size of any <spanx style="verb">DATA</spanx> frame headers that were lost.</t>
  <t>Loss of QUIC packets that only contain part of an HTTP/3 <spanx style="verb">DATA</spanx> frame Data field (i.e. beyond the frame header) can be recovered using the unicast repair mechanism described in <xref target="unicast-repair"/>.</t>
</list></t>

<t><xref target="H3-DATA-OFFSET"/> describes the <spanx style="verb">DATA_WITH_OFFSET</spanx> HTTP/3 extension frame type, which can be used to solve the third problem described above. Multicast QUIC sessions that make use of the <spanx style="verb">DATA_WITH_OFFSET</spanx> extension frame MUST advertise the session with the appropriate non-compatible experiment identifier “data-offset” in the ALPN string, as specified in <xref target="draft-version-id"/>.</t>

</section>
<section anchor="http3-extension-frames" title="HTTP/3 Extension frames">
<t>Except where explicitly allowed by this specification (e.g. in <xref target="http-quic-packet-loss"/> above), HTTP/3 extension frames (e.g. <spanx style="verb">ALTSVC</spanx>) are prohibited by this profile. Participants MUST NOT make any attempt to send prohibited extension frame types. Reception of these MUST be handled as described in <xref target="prohibited-hq-frames"/>.</t>

</section>
<section anchor="prohibited-hq-frames" title="Prohibited HTTP/3 Frames">
<t>The following HTTP/3 frames MUST NOT be transmitted by participants: <spanx style="verb">GOAWAY</spanx>, <spanx style="verb">MAX_PUSH_ID</spanx>, <spanx style="verb">SETTINGS</spanx>.</t>

<t>In addition, all HTTP/3 extension frame types MUST NOT be transmitted by participants.</t>

<t>The following HTTP/3 frames MUST NOT be transmitted by receivers: <spanx style="verb">CANCEL_PUSH</spanx>.</t>

<t>Reception of a prohibited HTTP/3 frame is a protocol error. Receivers MUST ignore prohibited HTTP/3 frames.</t>

</section>
</section>
<section anchor="app-layer-security" title="Application-Layer Security">

<t>As already described in <xref target="intro-security-params"/>, the implicit cipher suite used by a multicast QUIC session makes very limited provision for security in the transport and session layers. This section profiles the use of some additional features to provide equivalent functionality at the application-layer.</t>

<section anchor="security-integrity" title="Content Integrity">

<t>In many applications, it is important to ensure that an HTTP representation has been received intact (i.e. has not suffered from transmission loss or random bit errors) before passing the received object on to the receiving application. A mechanism is therefore specified here to provide end-to-end content integrity protection for HTTP representations in transit. The use of this content integrity mechanism is RECOMMENDED.</t>

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> We invite review comments on mandating the use of this content integrity mechanism.</t>
</list></t>

<t><xref target="RFC3230"/> specifies an instance digest HTTP header called <spanx style="verb">Digest</spanx>. A sender MAY include this header in the HTTP/3 <spanx style="verb">HEADERS</spanx> frame of any representation it transmits and a receiver MAY use this header to validate the integrity of the received representation once it has been reassembled. Where this validation fails, the receiver SHOULD discard the representation without processing it further.</t>

<t>Note that the digest value protects a whole HTTP instance (i.e. the representation of a resource at the point of transmission as opposed to the body of a particular HTTP message). In cases where partial representations are fragmented over one or more HTTP response messages, the digest value is computed over the complete representation prior to fragmentation into partial responses.</t>

<t>Any of the algorithms specified in the IANA registry of digest algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the <spanx style="verb">Digest</spanx> header. There is no requirement for participants to support the full set of algorithms.</t>

</section>
<section anchor="security-authenticity" title="Content Authenticity">

<t>In some applications, it is important for a receiver to reassure itself that an HTTP representation has been received from an authentic source. It is also sometimes useful for a receiver to know that the information has not been tampered with in transit by a malicious intermediate actor. A mechanism is therefore specified here to prove the authenticity of HTTP messages in transit. The use of this content authenticity mechanism is RECOMMENDED for senders implementing this specification.</t>

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> We invite review comments on mandating the use of this content authenticity mechanism.</t>
</list></t>

<t><xref target="I-D.cavage-http-signatures"/> specifies a means of securely signing metadata associated with any HTTP message. The resulting digital signature is conveyed in the <spanx style="verb">Signature</spanx> header of the message itself. The <spanx style="verb">Signature</spanx> header also conveys a list of HTTP header fields over which the signature was computed. A receiver MAY verify the <spanx style="verb">Signature</spanx> header in order to validate the authenticity of received metadata. Where this validation fails, the receiver SHOULD discard or ignore any related metadata and/or data without processing it further.</t>

<t>Note that the signature proves the authenticity of the metadata in a single HTTP message. A <spanx style="verb">Signature</spanx> header MAY be included separately in the HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx> frame (protecting the request metadata) and in the final (or only) HTTP/3 <spanx style="verb">HEADERS</spanx> frame relating to a particular resource (protecting the response metadata). In order to provide an additional level of protection, however, it is RECOMMENDED that the signature be computed over the combined request metadata (from the HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx> frame) and the corresponding response metadata (from the HTTP/3 <spanx style="verb">HEADERS</spanx> frames) of the same resource. This binds the request metadata and response metadata together, providing the receiver with additional reassurance of authenticity. In this latter case, the combined digital signature SHALL be conveyed in the final (or only) HTTP/3 <spanx style="verb">HEADERS</spanx> frame.</t>

<t>In applications where the detection of replay attacks is a requirement, it is RECOMMENDED that the <spanx style="verb">Date</spanx> header be included in the scope of the signature. It is RECOMMENDED that receivers use the value of the <spanx style="verb">Date</spanx> header for replay detection using appropriate strategies (e.g. checking for freshness). The definition of such strategies is beyond the scope of this document.</t>

<t>In applications where the authenticity and integrity of the transmission are both important, it is RECOMMENDED that the <spanx style="verb">Digest</spanx> header specified in <xref target="security-integrity"/> above is included in the scope of the signature. By signing the instance digest, the authenticity and integrity of the HTTP message body are also assured in addition to that of the metadata.</t>

<t>Any of the algorithms specified in the IANA registry of signature algorithms (http://www.iana.org/assignments/signature-algorithms) MAY be used in conjunction with the <spanx style="verb">Signature</spanx> header. There is no requirement for participants to support the full set of algorithms.</t>

</section>
<section anchor="security-confidentiality" title="Content Confidentiality">

<t>In applications where there is a requirement for the content itself to remain confidential, appropriate steps SHOULD be taken to protect the application payload, for example by encrypting it. This document does not preclude the use of application-level encryption, but does not specify a mechanism for the distribution of content decryption keys.</t>

</section>
</section>
<section anchor="loss-recovery" title="Loss Recovery">

<t>Because the acknowledgement of received packets to multicast groups is prohibited by this specification (<xref target="loss-detection"/>) the detection of discarded or corrupted packets is the sole responsibility of the receiver, and such losses must be recovered by means other than the retransmission mechanism specified in <xref target="RFC9000"/> and <xref target="RFC9002"/>.</t>

<section anchor="forward-error-correction" title="Forward Error Correction">

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> A simple parity-based Forward Error Correction scheme was removed from the experimental QUIC wire protocol specification in version Q032. The IETF’s QUIC Working Group is chartered to specify one (or more) new FEC schemes in the future. This section will track developments in this area, and will be updated accordingly.</t>
</list></t>

<t>A sender MAY make use of a suitable Forward Error Correction scheme to allow a receiver to reconstruct lost packets from those that have been successfully received.</t>

</section>
<section anchor="unicast-repair" title="Unicast Repair">

<t>In the case where a lost QUIC packet cannot be recovered using Forward Error Correction, either because the number of packets lost exceeds the scheme’s threshold for reconstruction, or because FEC is not in use on the multicast QUIC session, a receiver MAY instead recover the missing payload data using conventional unicast HTTP requests to an origin server.</t>

<t><list style="symbols">
  <t>The total size of the resource is indicated in the <spanx style="verb">content-length</spanx> response header carried in the HTTP/3 <spanx style="verb">HEADERS</spanx> frame.</t>
  <t>The location of the missing data can be determined by examining the Offset field in the QUIC <spanx style="verb">STREAM</spanx> frame headers of successfully received QUIC packets.</t>
</list></t>

<t>Using this information, a receiver MAY compose an efficient HTTP range request <xref target="RFC7233"/> to the origin server indicated in the URL. Several disjoint ranges MAY be combined into a single HTTP request. A receiver MAY direct its request to an alternative server using Alt-Svc information received on the multicast QUIC session, or else received as part of a previous unicast HTTP response according to the rules in <xref target="RFC7838"/>.</t>

</section>
</section>
<section anchor="partial-content" title="Transmission of Partial Content">

<t>Under certain circumstances, a sender may not be in full possession of a resource body when transmission begins, or may not be able to guarantee that a transmission will complete. In such cases, the sender MAY employ the syntax of an HTTP range request <xref target="RFC7233"/> to indicate partial content, as specified below. All receivers SHALL implement support for such HTTP range requests.</t>

<t>If partial content is to be transmitted:</t>

<t><list style="symbols">
  <t>The <spanx style="verb">range</spanx> header (Section 3.1 of <xref target="RFC7233"/>) SHALL be present in the HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx> frame.</t>
  <t>The corresponding HTTP/3 <spanx style="verb">HEADERS</spanx> frame SHALL indicate HTTP status code 206.
  <list style="symbols">
      <t>The range being transmitted SHALL be indicated in a <spanx style="verb">content-range</spanx> header field and the size of the complete resource indicated in a <spanx style="verb">content-length</spanx> header field.</t>
    </list></t>
</list></t>

</section>
<section anchor="protocol-id" title="Protocol Identifier">

<t>The HTTP over multicast QUIC protocol specified in this document is identified by the application-layer protocol negotiation (ALPN) <xref target="RFC7301"/> identifier “h3m”. The IANA registration of this protocol identifier can be found in <xref target="reg-proto-string"/>. This reserves the ALPN identifier space but describes a protocol that does not use TLS. The usage of the “h3m” identifier for discoverability is described in <xref target="discoverability"/>.</t>

<section anchor="draft-version-id" title="Draft Version Identification">

<t><list style='empty'>
  <t><spanx style="strong">RFC Editor’s Note:</spanx>  Please remove this section prior to publication of a final version of this document.</t>
</list></t>

<t>Only implementations of the final, published RFC can identify themselves as “h3m”. Until such an RFC exists, implementations MUST NOT identify themselves using this string.</t>

<t>Implementations of draft versions of the protocol MUST add the string “-“ and the corresponding draft number to the identifier. For example, draft-pardue-quic-http-mcast-06 is identified using the string “h3m-06”.</t>

<t>Non-compatible experiments that are based on these draft versions MUST append the string “-“ and an experiment name to the identifier. For example, an experimental implementation based on draft-pardue-quic-http-mcast-06 which uses extension features not registered with the appropriate IANA registry might identify itself as “h3m-06-extension-foo”. Note that any label MUST conform to the “token” syntax defined in Section 3.2.6 of <xref target="RFC7230"/>. Experimenters are encouraged to coordinate their experiments.</t>

</section>
</section>
<section anchor="discoverability" title="Discovery of Multicast QUIC Sessions">

<t>The announcement and discovery of services operating over multicast IP has previously been specified by the Session Description Protocol (SDP) <xref target="RFC4566"/>, Session Announcement Protocol <xref target="RFC2974"/> and Session Initiation Protocol <xref target="RFC3261"/>. These are typically deployed together and in conjunction with a multicast-friendly transport such as the Real-time Transport Protocol (RTP) <xref target="RFC3550"/>.</t>

<t>In contrast, the present document specifies a mechanism for advertising services that is built into HTTP metadata and is consistent across unicast and multicast resource delivery modes. This means that a single application-layer can be used for service advertisement/discovery, and for bulk data transmission/reception. Specifically, the <spanx style="verb">Alt-Svc</spanx> HTTP header is specified as the means to advertise multicast services from a unicast service. A unicast HTTP response MAY be decorated with an Alt-Svc value that hints to the client about the availability of the resource via a multicast QUIC session. A client that supports such a multicast QUIC session MAY then transparently switch to it.</t>

<t>Symmetrically, the <spanx style="verb">Alt-Svc</spanx> header can also be used to advertise the unicast service from a multicast service. A resource transmitted as part of a multicast QUIC session MAY be decorated with an Alt-Svc value that hints to the client about the availability of the resource via an alternative unicast HTTP server. A receiver MAY then use this HTTP server for unicast resource patching (<xref target="unicast-repair"/>).</t>

<t>Where HTTP over multicast QUIC sessions are advertised using Alt-Svc, the protocol identifier SHALL be “h3m”, as specified in <xref target="protocol-id"/>.</t>

<section anchor="param-source-address" title="Source-specific Multicast Advertisement">

<t>Source-specific multicast (SSM) <xref target="RFC4607"/> MAY be used for the delivery of multicast services.</t>

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> We invite review comments on mandating the use of source-specific multicast only.</t>
</list></t>

<t>This document specifies the “source-address” parameter for Alt-Svc, which is used to provide the SSM source address to endpoints.</t>

<t>Syntax:</t>

<figure><artwork><![CDATA[
source-address = uri-host; see RFC7230, Section 2.7
]]></artwork></figure>

<t>For example:</t>

<figure><artwork><![CDATA[
source-address=192.0.2.1
]]></artwork></figure>

<t>When a multicast QUIC session is provided using SSM, the <spanx style="verb">source-address</spanx> parameter MUST be advertised. If the parameter is repeated, the first occurrence MUST be used and subsequent occurrences MUST be ignored.</t>

</section>
<section anchor="session-param-advert" title="Session Parameter Advertisement">
<t>The concept of session parameters is introduced in <xref target="intro-session-params"/>. This section details how the session parameters are expressed as Alt-Svc parameters.</t>

<section anchor="param-cs" title="Cipher Suite">
<t>This document specifies the “cipher-suite” parameter for Alt-Svc, which carries the cipher suite in use by a multicast QUIC session. <spanx style="verb">cipher-suite</spanx> MUST contain one of the values contained in the TLS Cipher Suite Registry (http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4):</t>

<t>Syntax:</t>

<figure><artwork><![CDATA[
cipher-suite = 4*4 HEXDIG
]]></artwork></figure>

<t>For example, the following specifies cipher suite 0x13,0x01 (<spanx style="verb">TLS_AES_128_GCM_SHA256</spanx>):</t>

<figure><artwork><![CDATA[
cipher-suite=1301
]]></artwork></figure>

<t>The requirements for endpoint usage of <spanx style="verb">cipher-suite</spanx> are described in <xref target="intro-security-params"/>.</t>

</section>
<section anchor="param-key" title="Session Key">
<t>This document specifies the “key” parameter for Alt-Svc, which carries the cryptographic key in use by the multicast QUIC session.</t>

<t>Syntax:</t>

<figure><artwork><![CDATA[
key = *HEXDIG
]]></artwork></figure>

<t>For example:</t>

<figure><artwork><![CDATA[
key=4adf1eab9c2a37fd
]]></artwork></figure>

<t>The requirements for endpoint usage of <spanx style="verb">key</spanx> are described in <xref target="intro-security-params"/>.</t>

</section>
<section anchor="param-iv" title="Session Cipher Initialization Vector">
<t>This document specifies the “iv” parameter for Alt-Svc, which carries the cipher Initialization Vector (IV) in use by the multicast QUIC session.</t>

<t>Syntax:</t>

<figure><artwork><![CDATA[
iv = *HEXDIG
]]></artwork></figure>

<t>For example:</t>

<figure><artwork><![CDATA[
iv=4dbe593acb4d1577ad6ba7dc3189834e
]]></artwork></figure>

<t>The requirements for endpoint usage of <spanx style="verb">iv</spanx> are described in <xref target="intro-security-params"/>.</t>

</section>
<section anchor="param-session-id" title="Session Identification">
<t>This document defines the “session-id” parameter for Alt-Svc, which carries the multicast QUIC session identifier.</t>

<t>Syntax:</t>

<figure><artwork><![CDATA[
session-id = *HEXDIG
]]></artwork></figure>

<t>For example, the following specifies session 101 (0x65 hexadecimal):</t>

<figure><artwork><![CDATA[
session-id=65
]]></artwork></figure>

<t>The requirements for endpoint usage of <spanx style="verb">session-id</spanx> are described in <xref target="intro-session-id"/>. In the above example, the Destination Connection ID field in every QUIC packet header would be one byte in size. For a session-id of BADBEEF then then Destintation Connection ID field in every QUIC packet header would be four bytes in size.</t>

</section>
<section anchor="param-session-idle-timeout" title="Session Idle Timeout Period">
<t>This document specifies the “session-idle-timeout” parameter for Alt-Svc, which carries the idle timeout period in milliseconds of a multicast QUIC session.</t>

<t>Syntax:</t>

<figure><artwork><![CDATA[
session-idle-timeout = *DIGIT ; integer milliseconds
]]></artwork></figure>

<t>For example, the following specifies a one-minute session idle timeout period:</t>

<figure><artwork><![CDATA[
session-idle-timeout=60
]]></artwork></figure>

<t>The requirements for endpoint usage of <spanx style="verb">session-idle-timeout</spanx> are described in <xref target="intro-session-idle-timeout"/>.</t>

</section>
<section anchor="param-max-concurrent-resources" title="Resource Concurrency">
<t>This document specifies the “max-concurrent-resources” parameter for Alt-Svc, which expresses the maximum number of concurrent active resources from the sender in a multicast QUIC session.</t>

<t>Syntax:</t>

<figure><artwork><![CDATA[
max-concurrent-resources = *DIGIT ; unsigned 32-bit integer
]]></artwork></figure>

<t>For example, the following specifies that no more than 12 (decimal) resources will be concurrently active in the session:</t>

<figure><artwork><![CDATA[
max-concurrent-resources=12
]]></artwork></figure>

<t>The requirements for endpoint usage of <spanx style="verb">max-concurrent-resources</spanx> are described in <xref target="intro-resource-concurrency"/>.</t>

</section>
<section anchor="param-flow-rate" title="Session Peak Flow Rate">
<t>This document specifies the “peak-flow-rate” parameter for Alt-Svc, which expresses the expected maximum aggregate transfer rate of data from all sources of the multicast QUIC session.</t>

<t>Syntax:</t>

<figure><artwork><![CDATA[
peak-flow-rate = *DIGIT ; bits per second
]]></artwork></figure>

<t>For example, the following specifies a peak flow rate of 550 kbits/s in the session:</t>

<figure><artwork><![CDATA[
peak-flow-rate=550000
]]></artwork></figure>

<t>The requirements for endpoint usage of <spanx style="verb">peak-flow-rate</spanx> are described in <xref target="intro-peak-flow-rate"/>.</t>

</section>
<section anchor="param-digest-algorithm" title="Digest Algorithm">
<t>This document specifies the “digest-algorithm” parameter for Alt-Svc, which carries the digest algorithm in use by a multicast QUIC session. <spanx style="verb">digest-algorithm</spanx> MUST contain one of the values defined in the HTTP Digest Algorithm Values registry (https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1).</t>

<t>Syntax:</t>

<figure><artwork><![CDATA[
digest-algorithm = token
]]></artwork></figure>

<t>For example, the following specifies a digest algorithm of SHA-256:</t>

<figure><artwork><![CDATA[
digest-algorithm=SHA-256
]]></artwork></figure>

<t>The requirements for endpoint usage of <spanx style="verb">digest-algorithm</spanx> are described in <xref target="intro-digest-algorithm"/>.</t>

</section>
<section anchor="param-signature-algorithm" title="Signature Algorithm">
<t>This document specifies the “signature-algorithm” parameter for Alt-Svc, which carries the signature algorithm in use by a multicast QUIC session. <spanx style="verb">signature-algorithm</spanx> MUST contain one of the values defined in the Signature Algorithms registry (http://www.iana.org/assignments/signature-algorithms).</t>

<t>Syntax:</t>

<figure><artwork><![CDATA[
signature-algorithm = token
]]></artwork></figure>

<t>For example, the following specifies a signature algorithm of SHA-256:</t>

<figure><artwork><![CDATA[
signature-algorithm=rsa-sha256
]]></artwork></figure>

<t>The requirements for endpoint usage of <spanx style="verb">signature-algorithm</spanx> are described in <xref target="intro-signature-algorithm"/>.</t>

</section>
<section anchor="param-extensions" title="Extensions">
<t>This document specifies the “extensions” parameter for Alt-Svc, which carries a list of extension types potentially in use by a multicast QUIC session. <spanx style="verb">extensions</spanx> MUST only contain values from the QUIC Transport Parameter registry (<xref target="RFC9000"/>, section 22.3) that have explicit support for multicast QUIC. Each entry in the list consists of a key identifying the transport parameter, and an optional value. Both the key and the value are hex-encoded.</t>

<t>Syntax:</t>

<figure><artwork><![CDATA[
extensions           = DQUOTE ext-transport-param
                       *[ "," ext-transport-param ] DQUOTE
ext-transport-param  = ext-key [ "=" ext-value ]
ext-key              = 4*4HEXDIG; Transport Parameter key
ext-value            = *HEXDIG; Optional Transport Parameter value
]]></artwork></figure>

<t>For example, the following specifies two extensions:</t>

<figure><artwork><![CDATA[
extensions="0094,0d0d=f00"
]]></artwork></figure>

<t>The requirements for endpoint usage of <spanx style="verb">extensions</spanx> are described in <xref target="intro-extensions"/></t>

</section>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>This document specifies a profile of QUIC and HTTP/3 that changes the security model. In order to address this, application-level security methods are described in <xref target="app-layer-security"/>. This document does not preclude the use of secure multicast approaches that may provide additional security assurances required for certain use cases.</t>

<t>The use of side-channel or out-of-band technologies (potentially bidirectional interactions) to support multicast QUIC sessions are considered out of this document’s scope. Services using such technologies should apply their security considerations accordingly.</t>

<section anchor="pervasive-monitoring" title="Pervasive Monitoring">

<t>Certain multicast deployment architectures may require the use of a session decryption key shared by all participants. Furthermore, the discovery mechanism described in this document provides a means for a receiver to obtain a session decryption key without joining the session. The act of removing packet protection in order to inspect or modify application contents may, in certain deployments, be trivial. The exploration of restricting key learning or session joining to authorised participants goes beyond the scope of this document.</t>

<t>Because in-band multicast interactions are unidirectional, the impact of Pervasive Monitoring <xref target="RFC7258"/> on in-band traffic flows is inherently reduced. Actors can only inspect or modify sender-initiated traffic. Additional measures for content confidentiality may mitigate the impact further. This is discussed in <xref target="security-confidentiality"/>.</t>

<t>Further Pervasive Monitoring concerns are addressed in the following sections.</t>

<section anchor="large-scale-data-gathering-and-correlation" title="Large-scale Data Gathering and Correlation">
<t>Multicast QUIC sessions decouple sending and receiving participants. Session participation is subject to operations that allow an endpoint to join or leave a multicast group, typically IGMP <xref target="RFC3376"/> or MLD <xref target="RFC3810"/>. The propagation intent of these messages travelling deeper through a network hierarchy generally leads to the anonymisation of data if implemented as specified. It may be possible to gather user-identifiable messages close to the network edge, for example a router logging such messages. However, this would require wide-ranging access across Internet Service Provider networks. Therefore, while such attacks are feasible, it can be asserted that gathering and correlating user-identifiable traffic is difficult to perform covertly and at scale.</t>

</section>
<section anchor="changing-content" title="Changing Content">
<t>Sessions that use a symmetric key for packet protection are subject to the possibility of a malicious actor modifying traffic at some point in the network between a legitimate sender and one (or more) receivers. Receiver-side validation, as specified in <xref target="app-layer-security"/> of the present document, and also in <xref target="RFC9000"/>, allows for the detection of such modification. Two approaches help mitigate the impact of modification; the first is application-level methods that protect data (<xref target="security-integrity"/>) and metadata (<xref target="security-authenticity"/>); the second is reduction of the QUIC packet attack surface by means of removal of many frame types (<xref target="prohibited-quic-frames"/> and <xref target="prohibited-hq-frames"/>).</t>

</section>
</section>
<section anchor="security-cons-disc" title="Protection of Discovery Mechanism">
<t>Multicast QUIC session advertisements SHOULD be conveyed over a secure transport that guarantees authenticity and integrity in order to mitigate attacks related to a malicious service advertisement, for example a “man in the middle” directing endpoints to a service that may lead to other attacks or exploitations.</t>

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> We invite review comments on mandating the use of a secure transport for advertising sessions.</t>
</list></t>

<t>Endpoints that make use of multicast QUIC session advertisements SHOULD have reasonable assurance that the alternative service is under control of, and valid for, the whole origin, as described in Section 2.1 of <xref target="RFC7838"/>. <xref target="security-authenticity"/> discusses measures that may be used to fulfil this requirement.</t>

</section>
<section anchor="spoofing" title="Spoofing">

<section anchor="sender-spoofing" title="Sender Spoofing">
<t>A malicious actor may be able to stage a spoof attack by sending fake QUIC packets to a multicast QUIC session. This could affect the operation or behaviour of receivers. In a multicast scenario, this form of attack has the potential to scale massively.</t>

<t>The feasibility of spoofing a multicast sender is governed by the characteristics of the multicast deployment and network infrastructure. The use of source-specific multicast <xref target="RFC4607"/> may reduce the feasibility. The use of content authenticity (<xref target="security-authenticity"/>) may mitigate concerns for the application-level messages. However, there remains the possibility for transport-level messages to be spoofed. Multicast applications should consider further mitigations to address this concern.</t>

</section>
</section>
<section anchor="replay-attacks" title="Replay Attacks">
<t>Conventional QUIC strategies for protecting against replay attacks apply similarly here.</t>

<t>Certain multicast QUIC sessions may use a shared key for transport-level encryption, which would allow an attacker to record, decrypt, repackage and replay QUIC packets. <xref target="security-authenticity"/> discusses how the application-level contents may be protected from replay (by signing the <spanx style="verb">Date</spanx> HTTP header), which provides some mitigation to the success rate or effects of replay attacks.</t>

</section>
<section anchor="message-deletion" title="Message Deletion">
<t>Since HTTP over multicast QUIC is designed to tolerate unreliable delivery, the impacts of message deletion attacks are presumed to be small. Deletion of packets carrying HTTP headers will cause a receiver to ignore subsequent packets carrying body data. Furthermore, the use of multicast QUIC sessions is opportunistic; disruption in service (for example, deleting packets and causing a receiver to fail in construction of a content object) is mitigated by falling back to a unicast service. Considerations for how this may affect the performance of the unicast service are given in <xref target="dos-herd"/>.</t>

</section>
<section anchor="denial-of-service" title="Denial of Service">

<section anchor="unprotected-frames-and-packets" title="Unprotected Frames and Packets">

<t>The profile described in the present document provides the means for a multicast sender to protect QUIC packets with a shared key, which is not a strong protection. The weak protection of QUIC packets could present a denial-of-service risk. To mitigate the impact of handling such QUIC packets, certain frames and packets are prohibited as described in (<xref target="prohibited-quic-frames"/> and <xref target="prohibited-hq-frames"/>).</t>

<t>The frame types that are allowed by this profile do not present a risk of denial of service. Concerns over authenticity and integrity are addressed by the application-layer protection mechanisms described in <xref target="app-layer-security"/>.</t>

</section>
<section anchor="dos-net-perf" title="Network Performance Degradation">
<t>The possibility for malfunctioning or malicious participants to degrade the network is a broad issue and considered out of scope for this document. Guidelines and concerns discussed in UDP Best Practices <xref target="RFC8085"/> and other sources apply equally here. This specification does not preclude the use of network performance degradation mitigation solutions such as network circuit breakers.</t>

</section>
<section anchor="dos-herd" title="Unicast Repair Stampeding Herd">
<t>Deployments that support the unicast repair mechanism described in <xref target="unicast-repair"/> should be aware that a triggering of this behaviour (either deliberate, planned or unplanned) in a large population of multicast receivers may cause a stampeding herd of client requests to the unicast repair service. Service operators SHOULD mitigate the impact of stampeding herd on their deployment.</t>

</section>
</section>
<section anchor="receiver-resource-usage" title="Receiver Resource Usage">

<t>The application of receiver-side validation, as defined in the present document and in <xref target="RFC9000"/>, adds some protection against allocating resource to the processing of bad data.</t>

</section>
<section anchor="unicast-repair-information-leakage" title="Unicast Repair Information Leakage">
<t>The unicast repair mechanism may lead to the leakage of user behaviour data. An attacker could gain insight into any receiver participating in a multicast QUIC session, for example by monitoring the TCP port of the unicast alternative. This alone is no worse than current abilities to monitor unicast interactions, for example observing the SNI field contained in a TLS ClientHello. The complete protection of unicast interactions is beyond the scope of this document. However, knowledge that a user (or group of users) has participated in a session is sensitive and may be obtained by correlation between with observable multicast and unicast traffic.</t>

<t>To give an example, a malicious “man in the middle” could purposely cause all receivers to perform a unicast repair (by disrupting the QUIC traffic flow in some way). The disruption is untargeted and may be simple to orchestrate, but the correlation of user activity data, especially across a distributed repair service (e.g. a CDN), requires resources that may reduce the attractiveness of such an attack.</t>

<t>The ability for an attacker to disrupt multicast QUIC sessions is mitigated by this profile (mainly the prohibition of frames and packets). Application-layer security measures described in <xref target="app-layer-security"/> reduce the feasibility further.</t>

<t>Multicast receivers concerned about this form of leakage can eliminate this risk completely by disabling support for unicast repair, at the potential cost of reduced service quality.</t>

</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">

<section anchor="reg-proto-string" title="Registration of Protocol Identification String">
<t>This document creates a new registration for the identification of the HTTP over multicast QUIC protocol in the “Application-Layer Protocol Negotiation (ALPN) Protocol IDs” registry established by <xref target="RFC7301"/>.</t>

<t>The “h3m” string identifies HTTP semantics expressed as HTTP mapped to a QUIC layer and carried over IP multicast:</t>

<t><list style="hanging">
  <t hangText='Protocol:'>
  Bulk data transport using HTTP over multicast QUIC</t>
  <t hangText='Identification Sequence:'>
  0x68 0x33 0x6D (“h3m”)</t>
  <t hangText='Specification:'>
  This document, <xref target="protocol-id"/></t>
</list></t>

<t>This entry reserves an identifier that is not allowed to appear in TLS Application-Layer Protocol Negotiation.</t>

</section>
<section anchor="registration-of-alt-svc-parameters" title="Registration of Alt-Svc parameters">
<t>This document creates seven registrations for the identification of parameters for the “Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry” established by <xref target="RFC7838"/> (http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids).</t>

<section anchor="source-address" title="Source Address">
<t><list style="hanging">
  <t hangText='Parameter name:'>
  source-address</t>
  <t hangText='Specification:'>
  This document, <xref target="param-source-address"/></t>
</list></t>

</section>
<section anchor="cipher-suite-1" title="Cipher Suite">
<t><list style="hanging">
  <t hangText='Parameter name:'>
  cipher-suite</t>
  <t hangText='Specification:'>
  This document, <xref target="param-cs"/></t>
</list></t>

</section>
<section anchor="key" title="Key">
<t><list style="hanging">
  <t hangText='Parameter name:'>
  key</t>
  <t hangText='Specification:'>
  This document, <xref target="param-key"/></t>
</list></t>

</section>
<section anchor="initialization-vector-1" title="Initialization Vector">
<t><list style="hanging">
  <t hangText='Parameter name:'>
  iv</t>
  <t hangText='Specification:'>
  This document, <xref target="param-iv"/></t>
</list></t>

</section>
<section anchor="session-identifier" title="Session Identifier">
<t><list style="hanging">
  <t hangText='Parameter name:'>
  session-id</t>
  <t hangText='Specification:'>
  This document, <xref target="param-session-id"/></t>
</list></t>

</section>
<section anchor="session-idle-timeout" title="Session Idle Timeout">
<t><list style="hanging">
  <t hangText='Parameter name:'>
  session-idle-timeout</t>
  <t hangText='Specification:'>
  This document, <xref target="param-session-idle-timeout"/></t>
</list></t>

</section>
<section anchor="maximum-concurrent-resources" title="Maximum Concurrent Resources">
<t><list style="hanging">
  <t hangText='Parameter name:'>
  max-concurrent-resources</t>
  <t hangText='Specification:'>
  This document, <xref target="param-max-concurrent-resources"/></t>
</list></t>

</section>
<section anchor="peak-flow-rate" title="Peak Flow Rate">
<t><list style="hanging">
  <t hangText='Parameter name:'>
  peak-flow-rate</t>
  <t hangText='Specification:'>
  This document, <xref target="param-flow-rate"/></t>
</list></t>

</section>
<section anchor="digest-algorithm" title="Digest Algorithm">
<t><list style="hanging">
  <t hangText='Parameter name:'>
  digest-algorithm</t>
  <t hangText='Specification:'>
  This document, <xref target="param-digest-algorithm"/></t>
</list></t>

</section>
<section anchor="signature-algorithm" title="Signature Algorithm">
<t><list style="hanging">
  <t hangText='Parameter name:'>
  signature-algorithm</t>
  <t hangText='Specification:'>
  This document, <xref target="param-signature-algorithm"/></t>
</list></t>

</section>
<section anchor="extension" title="Extension">
<t><list style="hanging">
  <t hangText='Parameter name:'>
  extension</t>
  <t hangText='Specification:'>
  This document, <xref target="param-extensions"/></t>
</list></t>

</section>
</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>

<reference anchor="QUIC-HTTP" >
  <front>
    <title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
    <author initials="M." surname="Bishop" fullname="Mike Bishop" role="editor">
      <organization>Akamai</organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
</reference>
<reference anchor="QUIC-QPACK" >
  <front>
    <title>QPACK: Header Compression for HTTP over QUIC</title>
    <author initials="C." surname="Krasic" fullname="Charles 'Buck' Krasic" role="editor">
      <organization>Netflix</organization>
    </author>
    <author initials="M." surname="Bishop" fullname="Mike Bishop" role="editor">
      <organization>Akamai Technologies</organization>
    </author>
    <author initials="A." surname="Frindell" fullname="Alan Frindell" role="editor">
      <organization>Facebook</organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-quic-qpack-21"/>
</reference>
<reference anchor="H3-DATA-OFFSET" >
  <front>
    <title>An Offset Extension Frame For HTTP/3 Data</title>
    <author initials="S." surname="Hurst" fullname="Sam Hurst">
      <organization>BBC Research &amp; Development</organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Internet-Draft" value="draft-hurst-quic-http-data-offset-frame-01"/>
</reference>




<reference  anchor="RFC9000" target='https://www.rfc-editor.org/info/rfc9000'>
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author initials='J.' surname='Iyengar' fullname='J. Iyengar' role='editor'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2021' month='May' />
<abstract><t>This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t></abstract>
</front>
<seriesInfo name='RFC' value='9000'/>
<seriesInfo name='DOI' value='10.17487/RFC9000'/>
</reference>



<reference  anchor="RFC7838" target='https://www.rfc-editor.org/info/rfc7838'>
<front>
<title>HTTP Alternative Services</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<author initials='P.' surname='McManus' fullname='P. McManus'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke'><organization /></author>
<date year='2016' month='April' />
<abstract><t>This document specifies &quot;Alternative Services&quot; 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="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<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="RFC5234" target='https://www.rfc-editor.org/info/rfc5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker' role='editor'><organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'><organization /></author>
<date year='2008' month='January' />
<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="RFC7405" target='https://www.rfc-editor.org/info/rfc7405'>
<front>
<title>Case-Sensitive String Support in ABNF</title>
<author initials='P.' surname='Kyzivat' fullname='P. Kyzivat'><organization /></author>
<date year='2014' month='December' />
<abstract><t>This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.</t></abstract>
</front>
<seriesInfo name='RFC' value='7405'/>
<seriesInfo name='DOI' value='10.17487/RFC7405'/>
</reference>



<reference  anchor="RFC7230" target='https://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>



<reference  anchor="RFC7234" target='https://www.rfc-editor.org/info/rfc7234'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</t></abstract>
</front>
<seriesInfo name='RFC' value='7234'/>
<seriesInfo name='DOI' value='10.17487/RFC7234'/>
</reference>



<reference  anchor="RFC3168" target='https://www.rfc-editor.org/info/rfc3168'>
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
<author initials='K.' surname='Ramakrishnan' fullname='K. Ramakrishnan'><organization /></author>
<author initials='S.' surname='Floyd' fullname='S. Floyd'><organization /></author>
<author initials='D.' surname='Black' fullname='D. Black'><organization /></author>
<date year='2001' month='September' />
<abstract><t>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3168'/>
<seriesInfo name='DOI' value='10.17487/RFC3168'/>
</reference>



<reference  anchor="RFC3230" target='https://www.rfc-editor.org/info/rfc3230'>
<front>
<title>Instance Digests in HTTP</title>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></author>
<author initials='A.' surname='Van Hoff' fullname='A. Van Hoff'><organization /></author>
<date year='2002' month='January' />
<abstract><t>HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body.  However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding).  Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances.  Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest.  This document proposes HTTP extensions that solve these problems.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3230'/>
<seriesInfo name='DOI' value='10.17487/RFC3230'/>
</reference>


<reference anchor="I-D.cavage-http-signatures">
   <front>
      <title>Signing HTTP Messages</title>
      <author fullname="Mark Cavage">
	 <organization>Oracle</organization>
      </author>
      <author fullname="Manu Sporny">
	 <organization>Digital Bazaar</organization>
      </author>
      <date month="October" day="21" year="2019" />
      <abstract>
	 <t>   When communicating over the Internet using the HTTP protocol, it can
   be desirable for a server or client to authenticate the sender of a
   particular message.  It can also be desirable to ensure that the
   message was not tampered with during transit.  This document
   describes a way for servers and clients to simultaneously add
   authentication and message integrity to HTTP messages by using a
   digital signature.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-cavage-http-signatures-12" />
   <format type="TXT" target="https://www.ietf.org/archive/id/draft-cavage-http-signatures-12.txt" />
</reference>



<reference  anchor="RFC7233" target='https://www.rfc-editor.org/info/rfc7233'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='Y.' surname='Lafon' fullname='Y. Lafon' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems.  This document defines range requests and the rules for constructing and combining responses to those requests.</t></abstract>
</front>
<seriesInfo name='RFC' value='7233'/>
<seriesInfo name='DOI' value='10.17487/RFC7233'/>
</reference>



<reference  anchor="RFC7301" target='https://www.rfc-editor.org/info/rfc7301'>
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
<author initials='S.' surname='Friedl' fullname='S. Friedl'><organization /></author>
<author initials='A.' surname='Popov' fullname='A. Popov'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='E.' surname='Stephan' fullname='E. Stephan'><organization /></author>
<date year='2014' month='July' />
<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="RFC4607" target='https://www.rfc-editor.org/info/rfc4607'>
<front>
<title>Source-Specific Multicast for IP</title>
<author initials='H.' surname='Holbrook' fullname='H. Holbrook'><organization /></author>
<author initials='B.' surname='Cain' fullname='B. Cain'><organization /></author>
<date year='2006' month='August' />
<abstract><t>IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols.  For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use.  This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4607'/>
<seriesInfo name='DOI' value='10.17487/RFC4607'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC1112" target='https://www.rfc-editor.org/info/rfc1112'>
<front>
<title>Host extensions for IP multicasting</title>
<author initials='S.E.' surname='Deering' fullname='S.E. Deering'><organization /></author>
<date year='1989' month='August' />
<abstract><t>This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting.  Recommended procedure for IP multicasting in the Internet.  This RFC obsoletes RFCs 998 and 1054.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='5'/>
<seriesInfo name='RFC' value='1112'/>
<seriesInfo name='DOI' value='10.17487/RFC1112'/>
</reference>



<reference  anchor="RFC3550" target='https://www.rfc-editor.org/info/rfc3550'>
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='S.' surname='Casner' fullname='S. Casner'><organization /></author>
<author initials='R.' surname='Frederick' fullname='R. Frederick'><organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author>
<date year='2003' month='July' />
<abstract><t>This memorandum describes RTP, the real-time transport protocol.  RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.  RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.  The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.  RTP and RTCP are designed to be independent of the underlying transport and network layers.  The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes.  There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='64'/>
<seriesInfo name='RFC' value='3550'/>
<seriesInfo name='DOI' value='10.17487/RFC3550'/>
</reference>



<reference  anchor="RFC6726" target='https://www.rfc-editor.org/info/rfc6726'>
<front>
<title>FLUTE - File Delivery over Unidirectional Transport</title>
<author initials='T.' surname='Paila' fullname='T. Paila'><organization /></author>
<author initials='R.' surname='Walsh' fullname='R. Walsh'><organization /></author>
<author initials='M.' surname='Luby' fullname='M. Luby'><organization /></author>
<author initials='V.' surname='Roca' fullname='V. Roca'><organization /></author>
<author initials='R.' surname='Lehtonen' fullname='R. Lehtonen'><organization /></author>
<date year='2012' month='November' />
<abstract><t>This document defines File Delivery over Unidirectional Transport (FLUTE), a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks.  The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC 3926.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6726'/>
<seriesInfo name='DOI' value='10.17487/RFC6726'/>
</reference>



<reference  anchor="RFC5740" target='https://www.rfc-editor.org/info/rfc5740'>
<front>
<title>NACK-Oriented Reliable Multicast (NORM) Transport Protocol</title>
<author initials='B.' surname='Adamson' fullname='B. Adamson'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='J.' surname='Macker' fullname='J. Macker'><organization /></author>
<date year='2009' month='November' />
<abstract><t>This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services.  NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers.  A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP).  It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways.  The protocol leverages the use of FEC-based (forward error correction) repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design. This document obsoletes RFC 3940.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5740'/>
<seriesInfo name='DOI' value='10.17487/RFC5740'/>
</reference>



<reference  anchor="RFC8200" target='https://www.rfc-editor.org/info/rfc8200'>
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials='S.' surname='Deering' fullname='S. Deering'><organization /></author>
<author initials='R.' surname='Hinden' fullname='R. Hinden'><organization /></author>
<date year='2017' month='July' />
<abstract><t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t></abstract>
</front>
<seriesInfo name='STD' value='86'/>
<seriesInfo name='RFC' value='8200'/>
<seriesInfo name='DOI' value='10.17487/RFC8200'/>
</reference>



<reference  anchor="RFC8866" target='https://www.rfc-editor.org/info/rfc8866'>
<front>
<title>SDP: Session Description Protocol</title>
<author initials='A.' surname='Begen' fullname='A. Begen'><organization /></author>
<author initials='P.' surname='Kyzivat' fullname='P. Kyzivat'><organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<date year='2021' month='January' />
<abstract><t>This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566.</t></abstract>
</front>
<seriesInfo name='RFC' value='8866'/>
<seriesInfo name='DOI' value='10.17487/RFC8866'/>
</reference>



<reference  anchor="RFC2974" target='https://www.rfc-editor.org/info/rfc2974'>
<front>
<title>Session Announcement Protocol</title>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></author>
<author initials='E.' surname='Whelan' fullname='E. Whelan'><organization /></author>
<date year='2000' month='October' />
<abstract><t>This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors.  This memo defines an Experimental Protocol for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2974'/>
<seriesInfo name='DOI' value='10.17487/RFC2974'/>
</reference>



<reference  anchor="RFC9001" target='https://www.rfc-editor.org/info/rfc9001'>
<front>
<title>Using TLS to Secure QUIC</title>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<author initials='S.' surname='Turner' fullname='S. Turner' role='editor'><organization /></author>
<date year='2021' month='May' />
<abstract><t>This document describes how Transport Layer Security (TLS) is used to secure QUIC.</t></abstract>
</front>
<seriesInfo name='RFC' value='9001'/>
<seriesInfo name='DOI' value='10.17487/RFC9001'/>
</reference>



<reference  anchor="RFC7450" target='https://www.rfc-editor.org/info/rfc7450'>
<front>
<title>Automatic Multicast Tunneling</title>
<author initials='G.' surname='Bumgardner' fullname='G. Bumgardner'><organization /></author>
<date year='2015' month='February' />
<abstract><t>This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network.  The protocol uses UDP encapsulation and unicast replication to provide this functionality.</t><t>The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.</t></abstract>
</front>
<seriesInfo name='RFC' value='7450'/>
<seriesInfo name='DOI' value='10.17487/RFC7450'/>
</reference>



<reference  anchor="RFC4821" target='https://www.rfc-editor.org/info/rfc4821'>
<front>
<title>Packetization Layer Path MTU Discovery</title>
<author initials='M.' surname='Mathis' fullname='M. Mathis'><organization /></author>
<author initials='J.' surname='Heffner' fullname='J. Heffner'><organization /></author>
<date year='2007' month='March' />
<abstract><t>This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets.  This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4821'/>
<seriesInfo name='DOI' value='10.17487/RFC4821'/>
</reference>



<reference  anchor="RFC1191" target='https://www.rfc-editor.org/info/rfc1191'>
<front>
<title>Path MTU discovery</title>
<author initials='J.C.' surname='Mogul' fullname='J.C. Mogul'><organization /></author>
<author initials='S.E.' surname='Deering' fullname='S.E. Deering'><organization /></author>
<date year='1990' month='November' />
<abstract><t>This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path.  It specifies a small change to the way routers generate one type of ICMP message.  For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='1191'/>
<seriesInfo name='DOI' value='10.17487/RFC1191'/>
</reference>



<reference  anchor="RFC9002" target='https://www.rfc-editor.org/info/rfc9002'>
<front>
<title>QUIC Loss Detection and Congestion Control</title>
<author initials='J.' surname='Iyengar' fullname='J. Iyengar' role='editor'><organization /></author>
<author initials='I.' surname='Swett' fullname='I. Swett' role='editor'><organization /></author>
<date year='2021' month='May' />
<abstract><t>This document describes loss detection and congestion control mechanisms for QUIC.</t></abstract>
</front>
<seriesInfo name='RFC' value='9002'/>
<seriesInfo name='DOI' value='10.17487/RFC9002'/>
</reference>



<reference  anchor="RFC4566" target='https://www.rfc-editor.org/info/rfc4566'>
<front>
<title>SDP: Session Description Protocol</title>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></author>
<date year='2006' month='July' />
<abstract><t>This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4566'/>
<seriesInfo name='DOI' value='10.17487/RFC4566'/>
</reference>



<reference  anchor="RFC3261" target='https://www.rfc-editor.org/info/rfc3261'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='G.' surname='Camarillo' fullname='G. Camarillo'><organization /></author>
<author initials='A.' surname='Johnston' fullname='A. Johnston'><organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<author initials='R.' surname='Sparks' fullname='R. Sparks'><organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='E.' surname='Schooler' fullname='E. Schooler'><organization /></author>
<date year='2002' month='June' />
<abstract><t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3261'/>
<seriesInfo name='DOI' value='10.17487/RFC3261'/>
</reference>



<reference  anchor="RFC7258" target='https://www.rfc-editor.org/info/rfc7258'>
<front>
<title>Pervasive Monitoring Is an Attack</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2014' month='May' />
<abstract><t>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t></abstract>
</front>
<seriesInfo name='BCP' value='188'/>
<seriesInfo name='RFC' value='7258'/>
<seriesInfo name='DOI' value='10.17487/RFC7258'/>
</reference>



<reference  anchor="RFC3376" target='https://www.rfc-editor.org/info/rfc3376'>
<front>
<title>Internet Group Management Protocol, Version 3</title>
<author initials='B.' surname='Cain' fullname='B. Cain'><organization /></author>
<author initials='S.' surname='Deering' fullname='S. Deering'><organization /></author>
<author initials='I.' surname='Kouvelas' fullname='I. Kouvelas'><organization /></author>
<author initials='B.' surname='Fenner' fullname='B. Fenner'><organization /></author>
<author initials='A.' surname='Thyagarajan' fullname='A. Thyagarajan'><organization /></author>
<date year='2002' month='October' />
</front>
<seriesInfo name='RFC' value='3376'/>
<seriesInfo name='DOI' value='10.17487/RFC3376'/>
</reference>



<reference  anchor="RFC3810" target='https://www.rfc-editor.org/info/rfc3810'>
<front>
<title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title>
<author initials='R.' surname='Vida' fullname='R. Vida' role='editor'><organization /></author>
<author initials='L.' surname='Costa' fullname='L. Costa' role='editor'><organization /></author>
<date year='2004' month='June' />
<abstract><t>This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2).  MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes.  MLDv2 is designed to be interoperable with MLDv1.  MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3810'/>
<seriesInfo name='DOI' value='10.17487/RFC3810'/>
</reference>



<reference  anchor="RFC8085" target='https://www.rfc-editor.org/info/rfc8085'>
<front>
<title>UDP Usage Guidelines</title>
<author initials='L.' surname='Eggert' fullname='L. Eggert'><organization /></author>
<author initials='G.' surname='Fairhurst' fullname='G. Fairhurst'><organization /></author>
<author initials='G.' surname='Shepherd' fullname='G. Shepherd'><organization /></author>
<date year='2017' month='March' />
<abstract><t>The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms.  This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP.  Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</t><t>Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic.  They may also need to implement additional mechanisms, depending on how they use UDP.</t><t>Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.</t><t>This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.</t></abstract>
</front>
<seriesInfo name='BCP' value='145'/>
<seriesInfo name='RFC' value='8085'/>
<seriesInfo name='DOI' value='10.17487/RFC8085'/>
</reference>



<reference  anchor="RFC5737" target='https://www.rfc-editor.org/info/rfc5737'>
<front>
<title>IPv4 Address Blocks Reserved for Documentation</title>
<author initials='J.' surname='Arkko' fullname='J. Arkko'><organization /></author>
<author initials='M.' surname='Cotton' fullname='M. Cotton'><organization /></author>
<author initials='L.' surname='Vegoda' fullname='L. Vegoda'><organization /></author>
<date year='2010' month='January' />
<abstract><t>Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents.  This document describes the use of these blocks.  This document is not an Internet Standards Track  specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5737'/>
<seriesInfo name='DOI' value='10.17487/RFC5737'/>
</reference>



<reference  anchor="RFC6676" target='https://www.rfc-editor.org/info/rfc6676'>
<front>
<title>Multicast Addresses for Documentation</title>
<author initials='S.' surname='Venaas' fullname='S. Venaas'><organization /></author>
<author initials='R.' surname='Parekh' fullname='R. Parekh'><organization /></author>
<author initials='G.' surname='Van de Velde' fullname='G. Van de Velde'><organization /></author>
<author initials='T.' surname='Chown' fullname='T. Chown'><organization /></author>
<author initials='M.' surname='Eubanks' fullname='M. Eubanks'><organization /></author>
<date year='2012' month='August' />
<abstract><t>This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use. Some multicast addresses are derived from AS numbers or unicast addresses.  This document also explains how these can be used for documentation purposes.  This document is not an Internet Standards  Track specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6676'/>
<seriesInfo name='DOI' value='10.17487/RFC6676'/>
</reference>




    </references>


<section anchor="acknowledgements" title="Acknowledgements">
<t>The authors would like to thank the following for their contributions to the design described in the present document: Brandon Butterworth, Chris Poole, Craig Taylor and David Waring.</t>

<t>We are also grateful to Thomas Swindells and Magnus Westerlund for their helpful review comments.</t>

</section>
<section anchor="examples" title="Examples">

<t>This appendix contains examples of multicast QUIC session advertisement and resource transfer (with and without application-layer content security).</t>

<section anchor="appendix-session-advertisement" title="Session Advertisement">
<t>This section shows several different examples of an HTTP service advertising a multicast QUIC session. Examples are given in IPv4 form, using reserved address ranges as specified in <xref target="RFC5737"/> and <xref target="RFC6676"/>.</t>

<section anchor="source-specific-multicast-quic-session" title="Source-specific Multicast QUIC Session">

<t>Advertisement of a multicast QUIC session operating on the source-specific multicast group address 232.0.0.1 on port 2000 with the source address 192.0.2.1. The session ID is 16 (0x10) and the idle timeout is one minute. At most 10 resources may be concurrently active in the session and the flow rate should not exceed 10 kbits/s. The multicast transport is unencrypted.</t>

<t>HTTP Alternative Service header field:</t>

<figure><artwork><![CDATA[
Alt-Svc:
    h3m="232.0.0.1:2000"; source-address="192.0.2.1";
    session-id=10; session-idle-timeout=60;
    max-concurrent-resources=10; peak-flow-rate=10000
]]></artwork></figure>

</section>
<section anchor="source-specific-multicast-quic-session-with-transport-encryption-using-a-symmetric-key" title="Source-specific Multicast QUIC Session with Transport Encryption using a Symmetric Key">

<t>Advertisement of a multicast QUIC session operating on the IPv6 globally-scoped source-specific multicast group address ff3e::1234 on port 2000 with the source address 2001:db8::1. The session ID is 16 (0x10) and the idle timeout is one minute. At most 10 resources may be concurrently active in the session and the flow rate should not exceed 10 kbits/s. The multicast transport is encrypted using the AEAD cipher suite 0x13,0x01 (<spanx style="verb">TLS_AES_128_GCM_SHA256</spanx>) with the shared session key and IV provided.</t>

<t>HTTP Alternative Service header field:</t>

<figure><artwork><![CDATA[
Alt-Svc:
    h3m="[ff3e::1234]:2000"; source-address="2001:db8::1";
    session-id=10; session-idle-timeout=60;
    max-concurrent-resources=10; peak-flow-rate=10000;
    cipher-suite=1301; key=4adf1eab9c2a37fd;
    iv=4dbe593acb4d1577ad6ba7dc3189834e
]]></artwork></figure>

</section>
<section anchor="source-specific-multicast-quic-session-with-transport-encryption-content-integrity-and-authenticity" title="Source-specific Multicast QUIC Session with Transport Encryption, Content Integrity and Authenticity">

<t>Advertisement of a multicast QUIC session operating on the IPv6 globally-scoped source-specific multicast group address ff3e::1234 on port 2000 with the source address 2001:db8::1. The session ID is 16 (0x10) and the idle timeout is one minute. At most 10 resources may be concurrently active in the session and the flow rate should not exceed 10 kbits/s. The multicast transport is encrypted using the AEAD cipher suite 0x13,0x01 (<spanx style="verb">TLS_AES_128_GCM_SHA256</spanx>) with the shared session key and IV provided. Content integrity is in use with the digest algorithm set restricted to SHA-256. Content authenticity is in use with the signature algorithm set restricted to rsa-sha256.</t>

<t>HTTP Alternative Service header field:</t>

<figure><artwork><![CDATA[
Alt-Svc:
    h3m="[ff3e::1234]:2000"; source-address="2001:db8::1";
    session-id=10; session-idle-timeout=60;
    max-concurrent-resources=10; peak-flow-rate=10000;
    cipher-suite=1301; key=4adf1eab9c2a37fd;
    iv=4dbe593acb4d1577ad6ba7dc3189834e;
    digest-algorithm=SHA-256; signature-algorithm=rsa-sha256
]]></artwork></figure>

</section>
</section>
<section anchor="appendix-resource-transfer" title="Resource Transfer">

<t>This section shows several different examples of the HTTP message patterns for a single resource.</t>

<t>Examples that show HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx> or <spanx style="verb">HEADERS</spanx> frames describe the contents of enclosed header block fragments.</t>

<section anchor="transfer-without-content-integrity-or-authenticity" title="Transfer without Content Integrity or Authenticity">

<t>HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx> frame:</t>

<figure><artwork><![CDATA[
:method: GET
:scheme: https
:path: /files/example.txt
:authority: example.org
]]></artwork></figure>

<t>HTTP/3 <spanx style="verb">HEADERS</spanx> frame:</t>

<figure><artwork><![CDATA[
:status: 200
content-length: 100
content-type: text/plain
date: Fri, 20 Jan 2017 10:00:00 GMT
]]></artwork></figure>

<t>HTTP/3 <spanx style="verb">DATA</spanx> frame containing 100 bytes of response body data:</t>

<figure><artwork><![CDATA[
...
]]></artwork></figure>

</section>
<section anchor="transfer-of-partial-content-without-content-integrity-or-authenticity" title="Transfer of Partial Content without Content Integrity or Authenticity">

<t>In this example, partial content is transferred as described in <xref target="partial-content"/>. The <spanx style="verb">Range</spanx> request header is used to indicate the sender’s original intention to transfer all 100 bytes of the representation. The <spanx style="verb">Content-Range</spanx> response header indicates that only the first 50 bytes were actually sent.</t>

<t>HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx> frame:</t>

<figure><artwork><![CDATA[
:method: GET
:scheme: https
:path: /files/example.txt
:authority: example.org
range: bytes=0-*
]]></artwork></figure>

<t>HTTP/3 <spanx style="verb">HEADERS</spanx> frame:</t>

<figure><artwork><![CDATA[
:status: 206
content-length: 100
content-range: bytes 0-49/100
content-type: text/plain
date: Fri, 20 Jan 2017 10:00:00 GMT
]]></artwork></figure>

<t>HTTP/3 <spanx style="verb">DATA</spanx> frame containing 50 bytes of response body data:</t>

<figure><artwork><![CDATA[
...
]]></artwork></figure>

</section>
<section anchor="transfer-with-content-integrity-and-without-authenticity" title="Transfer with Content Integrity and without Authenticity">

<t>In this example, content integrity is assured by the inclusion of the <spanx style="verb">Digest</spanx> response header, as described in <xref target="security-integrity"/>.</t>

<t>HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx> frame:</t>

<figure><artwork><![CDATA[
:method: GET
:scheme: https
:path: /files/example.txt
:authority: example.org
]]></artwork></figure>

<t>HTTP/3 <spanx style="verb">HEADERS</spanx> frame including the <spanx style="verb">Digest</spanx> header:</t>

<figure><artwork><![CDATA[
:status: 200
content-length: 100
content-type: text/plain
date: Fri, 20 Jan 2017 10:00:00 GMT
digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo=
]]></artwork></figure>

<t>HTTP/3 <spanx style="verb">DATA</spanx> frame containing 100 bytes of response body data:</t>

<figure><artwork><![CDATA[
...
]]></artwork></figure>

</section>
<section anchor="partial-transfer-with-content-integrity-and-without-authenticity" title="Partial Transfer with Content Integrity and without Authenticity">

<t>In this example, partial content is transferred as described in <xref target="partial-content"/>. The <spanx style="verb">Range</spanx> request header is used to indicate the sender’s intention to transfer all 100 bytes of the representation. The <spanx style="verb">Content-Range</spanx> response header indicates that only the first 50 bytes were actually sent. Content integrity is assured by the inclusion of the <spanx style="verb">Digest</spanx> response header, as described in <xref target="security-integrity"/>.</t>

<t>HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx> frame:</t>

<figure><artwork><![CDATA[
:method: GET
:scheme: https
:path: /files/example.txt
:authority: example.org
range: bytes=0-*
]]></artwork></figure>

<t>HTTP/3 <spanx style="verb">HEADERS</spanx> frame including the <spanx style="verb">Digest</spanx> header:</t>

<figure><artwork><![CDATA[
:status: 206
content-length: 100
content-range: bytes 0-49/100
content-type: text/plain
date: Fri, 20 Jan 2017 10:00:00 GMT
digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo=
]]></artwork></figure>

<t>HTTP/3 <spanx style="verb">DATA</spanx> frame containing 50 bytes of response body data:</t>

<figure><artwork><![CDATA[
...
]]></artwork></figure>

</section>
<section anchor="transfer-with-content-integrity-and-authenticity" title="Transfer with Content Integrity and Authenticity">

<t>In this example, content integrity is assured by the inclusion of the <spanx style="verb">Digest</spanx> response header, as described in <xref target="security-integrity"/>. Content authenticity is assured separately for the request and the response messages by the <spanx style="verb">Signature</spanx> header which protects the header fields described in further detail below. The <spanx style="verb">Signature</spanx> header parameter <spanx style="verb">keyId</spanx> contains the URL of a file containing the public key related to the multicast sender’s private key used to create the digital signature.</t>

<t>HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx> frame including a <spanx style="verb">Signature</spanx> header protecting the <spanx style="verb">:method</spanx> and <spanx style="verb">:path</spanx> (the request target), as well as the <spanx style="verb">:scheme</spanx> and <spanx style="verb">:authority</spanx> of the pseudo-request:</t>

<figure><artwork><![CDATA[
:method: GET
:scheme: https
:path: /files/example.txt
:authority: example.org
signature: keyId="https://example.org/mcast-sender.example.org.pem",
    algorithm=rsa-sha256,
    headers="(request-target) :scheme :authority",
    signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA"
]]></artwork></figure>

<t>HTTP/3 <spanx style="verb">HEADERS</spanx> frame including a <spanx style="verb">Signature</spanx> header protecting the <spanx style="verb">:method</spanx>, <spanx style="verb">:path</spanx>, <spanx style="verb">:scheme</spanx> and <spanx style="verb">:authority</spanx> of the pseudo-request above, plus the <spanx style="verb">Date</spanx> and <spanx style="verb">Digest</spanx> of the response:</t>

<figure><artwork><![CDATA[
:status: 200
content-length: 100
content-type: text/plain
date: Fri, 20 Jan 2017 10:00:00 GMT
digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo=
signature: keyId="https://example.org/mcast-sender.example.org.pem",
    algorithm=rsa-sha256,
    headers="(request-target) :scheme :authority date digest",
    signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y"
]]></artwork></figure>

<t>HTTP/3 <spanx style="verb">DATA</spanx> frame containing response body data:</t>

<figure><artwork><![CDATA[
...
]]></artwork></figure>

</section>
<section anchor="partial-transfer-with-content-integrity-and-authenticity" title="Partial Transfer with Content Integrity and Authenticity">

<t>In this example, partial content is transferred and the <spanx style="verb">Range</spanx> header (as described in <xref target="partial-content"/>) is used to indicate that 50 bytes out of 100 bytes were transferred. Content integrity is provided by the inclusion of the <spanx style="verb">Digest</spanx> header, as described in <xref target="security-integrity"/>. Authenticity is provided by the <spanx style="verb">Signature</spanx> header which protects the header fields described in further detail. The <spanx style="verb">Signature</spanx> header parameter <spanx style="verb">keyId</spanx> contains the URL of a file containing the public key related to the multicast sender’s private key used to create the digital signature.</t>

<t>HTTP/3 <spanx style="verb">PUSH_PROMISE</spanx> frame:</t>

<figure><artwork><![CDATA[
:method: GET
:scheme: https
:path: /files/example.txt
:authority: example.org
range: bytes=0-*
signature: keyId="https://example.org/mcast-sender.example.org.pem",
    algorithm=rsa-sha256,
    headers="(request-target) :scheme :authority range",
    signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA"
]]></artwork></figure>

<t>HTTP/3 <spanx style="verb">HEADERS</spanx> frame protecting the <spanx style="verb">:method</spanx>, <spanx style="verb">:path</spanx>, <spanx style="verb">:scheme</spanx> and <spanx style="verb">:authority</spanx> of the pseudo-request above, plus the <spanx style="verb">Date</spanx>, <spanx style="verb">Digest</spanx> and <spanx style="verb">Content-Range</spanx> of the response:</t>

<figure><artwork><![CDATA[
:status: 206
content-length: 100
content-range: bytes 0-49/100
content-type: text/plain
date: Fri, 20 Jan 2017 10:00:00 GMT
digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo=
signature: keyId="https://example.org/mcast-sender.example.org.pem",
    algorithm=rsa-sha256,
    headers="(request-target) :scheme :authority
        date digest content-range",
    signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y"
]]></artwork></figure>

<t>HTTP/3 <spanx style="verb">DATA</spanx> frame containing response body data:</t>

<figure><artwork><![CDATA[
...
]]></artwork></figure>

</section>
</section>
</section>
<section anchor="appendix-differences-summary-tables" title="Summary of differences from unicast QUIC and HTTP/3">

<texttable title="Cryptography and Transport" anchor="crypto-trans-table">
      <ttcol align='left'>Protocol feature</ttcol>
      <ttcol align='left'>Unicast QUIC</ttcol>
      <ttcol align='left'>Multicast QUIC profile</ttcol>
      <c>Packet number spaces</c>
      <c>QUIC transport packets are seperated into three distinct packet number spaces: initial, handshake and application data.</c>
      <c>All packets are numbered in the application data packet number space.</c>
      <c>Transport handshake</c>
      <c>Combined cryptographic and transport handshake stream conveying TLS handshake messages in QUIC Initial and Handshake packets.</c>
      <c>Not used.</c>
      <c>TLS cipher suite</c>
      <c>Client’s preferred cipher suite included in Client Hello message.</c>
      <c>Cipher suite optionally advertised out of band via Alt-Svc <spanx style="verb">cipher-suite</spanx> parameter. Default cipher suite is <spanx style="verb">0x00,0x00 (NULL_WITH_NULL_NULL)</spanx>.</c>
      <c>TLS session key</c>
      <c>Session key included in Server Hello message.</c>
      <c>Session key optionally advertised out of band via Alt-Svc <spanx style="verb">key</spanx> parameter.</c>
      <c>TLS initialization vector</c>
      <c>Initialization vector included in Server Hello message.</c>
      <c>Initialization vector optionally advertised out of band via Alt-Svc <spanx style="verb">iv</spanx> parameter.</c>
</texttable>

<texttable title="Required Transport Parameters" anchor="req-trans-param-table">
      <ttcol align='left'>Protocol feature</ttcol>
      <ttcol align='left'>Unicast QUIC</ttcol>
      <ttcol align='left'>Multicast QUIC profile</ttcol>
      <c><spanx style="verb">initial_max_data</spanx></c>
      <c>Connection-level flow control window size.</c>
      <c>Not used. Peak flow rate of a session optionally advertised out of band via Alt-Svc <spanx style="verb">peak-flow-rate</spanx> parameter.</c>
      <c><spanx style="verb">initial_max_stream_data_bidi_local</spanx></c>
      <c>Locally-initiated bidirectional stream flow control window size.</c>
      <c>Not used. No bidirectional streams in this profile.</c>
      <c><spanx style="verb">initial_max_stream_data_bidi_remote</spanx></c>
      <c>Remotely-initiated bidirectional stream flow control window size.</c>
      <c>Not used. No bidirectional streams in this profile.</c>
      <c><spanx style="verb">initial_max_stream_data_uni</spanx></c>
      <c>Unidirectional stream flow control window size.</c>
      <c>Not used. Peak flow rate of a session optionally advertised out of band via Alt-Svc <spanx style="verb">peak-flow-rate parameter</spanx>.</c>
      <c><spanx style="verb">initial_max_streams_bidi</spanx> and <spanx style="verb">initial_max_streams_uni</spanx></c>
      <c>Maximum stream concurrency.</c>
      <c>Not used. Maximum concurrent resources in a session optionally advertised out of band via Alt-Svc <spanx style="verb">max-concurrent-resources</spanx> parameter.</c>
</texttable>

<texttable title="Optional Transport Parameters" anchor="opt-trans-param-table">
      <ttcol align='left'>Protocol feature</ttcol>
      <ttcol align='left'>Unicast QUIC</ttcol>
      <ttcol align='left'>Multicast QUIC profile</ttcol>
      <c><spanx style="verb">original_destination_connection_id</spanx></c>
      <c>The value of the Destination Connection ID field from the first Initial packet sent by the client.</c>
      <c>Not used. No client interaction.</c>
      <c><spanx style="verb">max_idle_timeout</spanx></c>
      <c>How long to keep an idle connection open for before closing. Takes a default of 0 (never close on idle) if not specified.</c>
      <c>Not used. Advertised out of band via Alt-Svc <spanx style="verb">session-idle-timeout</spanx> parameter; defaults to 0 (never close on idle) if not specified.</c>
      <c><spanx style="verb">stateless_reset_token</spanx></c>
      <c>Used in verifying a stateless reset.</c>
      <c>Not used. Stateless reset is not used by this profile.</c>
      <c><spanx style="verb">max_udp_payload_size</spanx></c>
      <c>Limit of the size of packets that an endpoint is willing to receive.</c>
      <c>Not used. Maximum packet size for a session optionally advertised out of band via Alt-Svc <spanx style="verb">max-packet-size</spanx> parameter.</c>
      <c><spanx style="verb">ack_delay_exponent</spanx></c>
      <c>The exponent used to decode the ACK Delay field in the <spanx style="verb">ACK</spanx> frame.</c>
      <c>Not used. <spanx style="verb">ACK</spanx> frames are prohibited by this profile.</c>
      <c><spanx style="verb">max_ack_delay</spanx></c>
      <c>Maximum time in milliseconds by which an endpoint will delay sending acknowledgements.</c>
      <c>Not used. <spanx style="verb">ACK</spanx> frames are prohibited by this profile.</c>
      <c><spanx style="verb">disable_active_migration</spanx></c>
      <c>Signals if an endpoint does not support connection migration.</c>
      <c>Not used. Session migration not currently supported by this profile.</c>
      <c><spanx style="verb">preferred_address</spanx></c>
      <c>Used to effect a change in server address at the end of the handshake.</c>
      <c>Not used. No handshake in this profile.</c>
      <c><spanx style="verb">active_connection_id_limit</spanx></c>
      <c>&#160;</c>
      <c>Not used. Only a single session identifier is used in this profile.</c>
      <c><spanx style="verb">initial_source_connection_id</spanx></c>
      <c>The value that an endpoint included in the Source Connection ID field of the first Initial packet it sent for the connection</c>
      <c>Not used. No client interaction.</c>
      <c><spanx style="verb">retry_source_connection_id</spanx></c>
      <c>The value that the server included in the Source Connection ID field of a retry packet</c>
      <c>Not used. Retry packets are not used in this profile.</c>
</texttable>

<texttable title="QUIC Packet Layer" anchor="quic-packet-table">
      <ttcol align='left'>Protocol feature</ttcol>
      <ttcol align='left'>Unicast QUIC</ttcol>
      <ttcol align='left'>Multicast QUIC profile</ttcol>
      <c>Maximum packet size</c>
      <c>Determined by path MTU discovery or other heuristic.</c>
      <c>Determined by path MTU discovery or other heuristic.</c>
      <c>Long header packet</c>
      <c>Used for packets that are sent prior to the completion of version negotiation and before packet protection keys are established.</c>
      <c>Prohibited.</c>
      <c>Version negotiation packet</c>
      <c>Protocol version negotiation between initiating client and server.</c>
      <c>Not permitted.</c>
      <c>Stateless reset packet</c>
      <c>Used by a peer to terminate a connection that has become unusable.</c>
      <c>Not permitted. (Potential denial-of-service attack vector.)</c>
      <c>Short header packet</c>
      <c>Used for packets that are sent once a connection has been established. Used to convey QUIC frames (see below).</c>
      <c>Used to convey QUIC frames (see below).</c>
      <c>Source Connection ID field, Destination Connection ID field</c>
      <c>Connection IDs negotiated between client and server during handshake and may be changed subsequently using the <spanx style="verb">NEW_CONNECTION_ID</spanx> frame.</c>
      <c>Source Connection ID not used. Destination Connection ID redefined to be a Multicast Session ID which is optionally advertised out of band via the Alt-Svc <spanx style="verb">session-id</spanx> parameter. May be omitted from packets if the address/port tuple is sufficient to identify the session, in which case it is not advertised.</c>
</texttable>

<texttable title="QUIC Framing Layer" anchor="quic-framing-table">
      <ttcol align='left'>Protocol feature</ttcol>
      <ttcol align='left'>Unicast QUIC</ttcol>
      <ttcol align='left'>Multicast QUIC profile</ttcol>
      <c><spanx style="verb">PADDING</spanx> frame</c>
      <c>Used to pad out a QUIC packet with zero bytes. (The first packet sent on a connection must be at least 1200 bytes long to prove that the network can transmit packets of at least this size.)</c>
      <c>Permitted, but wasteful of network capacity.</c>
      <c><spanx style="verb">PING</spanx> frame</c>
      <c>Used by an endpoint to verify that its peer is still alive. Acknowledged using a regular <spanx style="verb">ACK</spanx> frame.</c>
      <c>Used by the multicast sender as a session keep-alive notification. Never acknowledged.</c>
      <c><spanx style="verb">ACK</spanx> frames</c>
      <c>Used by a receiver to acknowledge receipt of data from its peer.</c>
      <c>Both <spanx style="verb">ACK</spanx> frame types are prohibited.</c>
      <c><spanx style="verb">RESET_STREAM</spanx> frame</c>
      <c>Request by receiver for sender to terminate a stream transmission prematurely.</c>
      <c>Indication to receivers that the multicast sender has prematurely terminated a stream transmission. Prohibited for receivers to send.</c>
      <c><spanx style="verb">STOP_SENDING</spanx> frame</c>
      <c>Flow control back pressure. Used to signal to a peer that incoming data on a stream is being discarded on receipt at the application’s request. This abruptly terminates a stream.</c>
      <c>Prohibited.</c>
      <c><spanx style="verb">CRYPTO</spanx> frame</c>
      <c>Used to transmit cryptographic handshake messages.</c>
      <c>Prohibited.</c>
      <c><spanx style="verb">NEW_TOKEN</spanx> frame</c>
      <c>Used by a server to supply a token to its client to be sent in the header of an initial packet for a future connection. Used to facilitate connection migration.</c>
      <c>Prohibited. Session migration not currently supported by this profile.</c>
      <c><spanx style="verb">STREAM</spanx> frame</c>
      <c>Conveys application-layer payloads (see HTTP/3 mapping below).</c>
      <c>Conveys application-layer payloads (see HTTP/3 mapping below).</c>
      <c><spanx style="verb">FIN</spanx> bit on <spanx style="verb">STREAM</spanx> frame</c>
      <c>Indication by sender to its peer that a stream transmission has finished.</c>
      <c>Indication by the multicast sender that a stream transmission has finished.</c>
      <c><spanx style="verb">MAX_DATA</spanx> frame</c>
      <c>Flow control update notification.</c>
      <c>Prohibited.</c>
      <c><spanx style="verb">MAX_STREAM_DATA</spanx> frame</c>
      <c>Flow control update notification.</c>
      <c>Prohibited.</c>
      <c><spanx style="verb">MAX_STREAMS</spanx> frame</c>
      <c>Used by an endpoint to inform a peer of the maximum stream ID that it is permitted to open.</c>
      <c>Prohibited.</c>
      <c><spanx style="verb">DATA_BLOCKED</spanx> frame</c>
      <c>Notification to receiver that sender’s transmission is blocked pending an update to its flow control window by peer.</c>
      <c>Prohibited.</c>
      <c><spanx style="verb">STREAM_DATA_BLOCKED</spanx> frame</c>
      <c>Notification to receiver that sender’s transmission of a single stream is blocked pending an update to its flow control window by peer.</c>
      <c>Prohibited.</c>
      <c><spanx style="verb">STREAMS_BLOCKED</spanx> frames</c>
      <c>Notification to receiver that the sender wishes to open a stream but is unable to do so because the maximum stream ID has been reached for a given stream type.</c>
      <c>Prohibited.</c>
      <c><spanx style="verb">NEW_CONNECTION_ID</spanx> frame</c>
      <c>Used to provide a peer with alternative connection IDs that can be used to break linkability when migrating connections.</c>
      <c>Prohibited. Session migration not currently supported by this profile.</c>
      <c><spanx style="verb">RETIRE_CONNECTION_ID</spanx> frame</c>
      <c>Indicates that an endpoint will no longer use a connection ID that was issued by its peer.</c>
      <c>Prohibited. Session migration not currently supported by this profile.</c>
      <c><spanx style="verb">PATH_CHALLENGE</spanx> frame</c>
      <c>Used to check reachability to a peer and for path validation during connection migration.</c>
      <c>Prohibited.</c>
      <c><spanx style="verb">PATH_RESPONSE</spanx> frame</c>
      <c>Sent in response to a <spanx style="verb">PATH_CHALLENGE</spanx> frame.</c>
      <c>Prohibited.</c>
      <c><spanx style="verb">CONNECTION_CLOSE</spanx> frame</c>
      <c>Notification (by either peer) of graceful connection shutdown.</c>
      <c>Prohibited. Use HTTP explicit session tear-down instead (see <xref target="http-quic-session-tear-down"/>).</c>
      <c><spanx style="verb">HANDSHAKE_DONE</spanx> frame</c>
      <c>Used by a server to inform a client that the cryptographic handshake has completed.</c>
      <c>Prohibited.</c>
</texttable>

<texttable title="HTTP/3 Mapping" anchor="http-quic-mapping-table">
      <ttcol align='left'>Protocol feature</ttcol>
      <ttcol align='left'>Unicast HTTP/3</ttcol>
      <ttcol align='left'>Multicast HTTP/3 profile</ttcol>
      <c>Stream Type</c>
      <c>Type of unidirectional stream.</c>
      <c>Only Server Push type is permitted.</c>
      <c>Push ID</c>
      <c>Identifies a promised resource conveyed in an earlier <spanx style="verb">PUSH_PROMISE</spanx> frame.</c>
      <c>Identifies a promised resource conveyed in an earlier <spanx style="verb">PUSH_PROMISE</spanx> frame.</c>
      <c><spanx style="verb">DATA</spanx> frame</c>
      <c>Carriage of HTTP request/response message body.</c>
      <c>Carriage of HTTP response message body.</c>
      <c><spanx style="verb">HEADERS</spanx> frame</c>
      <c>Carriage of HTTP request/response message metadata. Trailing <spanx style="verb">HEADERS</spanx> frame is permitted.</c>
      <c>Carriage of HTTP response message metadata. Trailing <spanx style="verb">HEADERS</spanx> frame is permitted.</c>
      <c><spanx style="verb">CANCEL_PUSH</spanx> frame</c>
      <c>Used to request cancellation of server push prior to the push stream being created.</c>
      <c>Permitted only for senders.</c>
      <c><spanx style="verb">SETTINGS</spanx> frame</c>
      <c>Negotiation of HTTP/3 connection settings.</c>
      <c>Prohibited.</c>
      <c><spanx style="verb">PUSH_PROMISE</spanx> frame</c>
      <c>Carriage of HTTP pseudo-request message metadata.</c>
      <c>Carriage of HTTP pseudo-request message metadata. All HTTP representation transfers over multicast begin this way. Stream ID of the first client-initiated bidirectional stream is reserved and all <spanx style="verb">PUSH_PROMISE</spanx> frames reference this as the client request from which they are notionally derived. This stream remains open while a sender is participating in the multicast QUIC session.</c>
      <c><spanx style="verb">GOAWAY</spanx> frame</c>
      <c>Early notification (by either endpoint) of future connection closure, allowing for orderly completion of open streams.</c>
      <c>Prohibited. Use HTTP explicit session tear-down instead.</c>
      <c><spanx style="verb">MAX_PUSH_ID</spanx> frame</c>
      <c>Used by a receiver to control the number of server pushes that a sender can initiate.</c>
      <c>Prohibited.</c>
      <c><spanx style="verb">ALTSVC</spanx> HTTP/2 extension frame</c>
      <c>Signalling alternative service for HTTP/3 session.</c>
      <c>Prohibited.</c>
      <c>Other HTTP/2 extension frames</c>
      <c>&#160;</c>
      <c>Prohibited.</c>
</texttable>

<texttable title="HTTP Metadata Compression Layer" anchor="http-metadata-compression-table">
      <ttcol align='left'>Protocol feature</ttcol>
      <ttcol align='left'>Unicast HTTP/3</ttcol>
      <ttcol align='left'>Multicast HTTP/3 profile</ttcol>
      <c>Huffman string compression</c>
      <c>Header blocks may use Huffman codes to compress literal string values.</c>
      <c>Header blocks may use Huffman codes to compress literal string values.</c>
      <c>Static table</c>
      <c>Header blocks may refer to indexed entries in the static table.</c>
      <c>Header blocks may refer to indexed entries in the static table.</c>
      <c>Dynamic table</c>
      <c>Header blocks may insert entries into the dynamic table and subsequent header blocks may refer to their indexes. Unused as size is currently locked to 0.</c>
      <c>Prohibited, size is currently locked to 0.</c>
</texttable>

</section>
<section anchor="changelog" title="Changelog">

<t><list style='empty'>
  <t><spanx style="strong">RFC Editor’s Note:</spanx> Please remove this section prior to publication of a
final version of this document.</t>
</list></t>

<section anchor="since-draft-pardue-quic-http-mcast-08" title="Since draft-pardue-quic-http-mcast-08">

<t><list style="symbols">
  <t>Update references to QUIC WG I-Ds to <xref target="RFC9000"/>, <xref target="RFC9001"/> and <xref target="RFC9002"/>.</t>
  <t>Update reference to DATA_WITH_OFFSET frame draft.</t>
</list></t>

</section>
<section anchor="since-draft-pardue-quic-http-mcast-07" title="Since draft-pardue-quic-http-mcast-07">

<t><list style="symbols">
  <t>Update references to QUIC WG I-Ds.</t>
  <t>Remove stale references to sections of the QUIC WG I-Ds that don’t exist any more.</t>
  <t>Add references to the DATA_WITH_OFFSET frame I-D.</t>
</list></t>

</section>
<section anchor="since-draft-pardue-quic-http-mcast-06" title="Since draft-pardue-quic-http-mcast-06">

<t><list style="symbols">
  <t>Update references to QUIC WG I-Ds.</t>
  <t>Clarify that only the first source-address parameter should be used if duplicated.</t>
  <t>Fix source-address example to not be a quoted string.</t>
  <t>Fix bytes in the ALPN identification sequence following change to h3m.</t>
  <t>Update language around QUIC Connection IDs to reflect the core specs.</t>
  <t>Update frame and transport parameter names throughout to match core specifications.</t>
  <t>Remove Author’s Note about reserved stream ID for <spanx style="verb">PUSH_PROMISE</spanx> frames.</t>
  <t>Update language around QPACK static and dynamic table indexing to more closely align with the core spec.</t>
  <t>Update Session Idle Timeout to match core specs, including removing limitation of 600 seconds and expressing in milliseconds, not seconds.</t>
  <t>Preface Session Termination with a statement clarifying that participants may leave at any time.</t>
</list></t>

</section>
<section anchor="since-draft-pardue-quic-http-mcast-05" title="Since draft-pardue-quic-http-mcast-05">

<t><list style="symbols">
  <t>Update references to QUIC WG I-Ds.</t>
  <t>Sender packet number size is now fixed for the duration of a session.</t>
  <t>Change how to handle multiple session IDs: sessions are now only allowed a single ID.</t>
  <t>Remove incompatible requirements set by <xref target="RFC9000"/>’s “Required Operations”.</t>
  <t>Additionally ban <spanx style="verb">HANDSHAKE_DONE</spanx>.</t>
  <t>Remove Version Negotiation now that the <spanx style="verb">quic</spanx> Alt-Svc parameter has been removed (examples also updated).</t>
  <t>Remove HTTP Prioritization references.</t>
  <t>Add new <spanx style="verb">extensions</spanx> Alt-Svc parameter.</t>
  <t>Broaden peak flow rate to QUIC payload to encompass all frame types.</t>
  <t>Change ALPN identifier to h3m.</t>
</list></t>

</section>
<section anchor="since-draft-pardue-quic-http-mcast-04" title="Since draft-pardue-quic-http-mcast-04">

<t><list style="symbols">
  <t>Update references to QUIC WG I-Ds, remove QUIC-SPIN. (draft-ietf-quic-transport-20)</t>
  <t>Update session ID length to match new connection ID length. (draft-ietf-quic-transport-22)</t>
  <t>Clarify the mapping for the new <spanx style="verb">active_connection_id_limit</spanx> session parameter. (draft-ietf-quic-transport-21)</t>
  <t>Update text to conform with latest version negotiation text from <xref target="RFC9000"/>.</t>
  <t>Update stream types for server push in accordance with draft-ietf-quic-http-19.</t>
  <t>Fix some idnits warnings to do with line lengths in Alt-Svc examples.</t>
  <t>Update IPv6 informative reference to RFC 8200 as it obsoletes RFC 2460.</t>
  <t>Clarify difference between connection and session migration.</t>
  <t>Move GOAWAY frame to HTTP/3 profile.</t>
  <t>Renamed Session Shutdown to Connection Shutdown to mirror concept in <xref target="RFC9000"/>.</t>
  <t>Clarify the layer of each frame type when referred to.</t>
</list></t>

</section>
<section anchor="since-draft-pardue-quic-http-mcast-03" title="Since draft-pardue-quic-http-mcast-03">

<t><list style="symbols">
  <t>Update references to QUIC WG I-Ds.</t>
  <t>Change crypto handshake text now that it’s no longer done on Stream ID 0.</t>
  <t>Update to reference Source and Destination Connection IDs.</t>
  <t>Prohibit the use of connection coalescing, migration and ECN.</t>
  <t>Update allowed and disallowed packets and frames to match the core specs.</t>
  <t>Remove references to the PONG frame. (draft-ietf-quic-transport-10)</t>
  <t>Change HTTP/QUIC to HTTP/3. (draft-ietf-quic-http-17)</t>
  <t>Change HPACK to QPACK. (draft-ietf-quic-http-10)</t>
  <t>Prohibit the DUPLICATE_PUSH frame.</t>
  <t>Clarify packet number space (only use application data space, not initial or handshake).</t>
  <t>Add statement on QUIC latency spin bit.</t>
  <t>Removed sentence stating that multiple Connection IDs cannot be used concurrently in a unicast QUIC session, in accordance with <xref target="RFC9000"/> section 5.1.2.</t>
</list></t>

</section>
<section anchor="since-draft-pardue-quic-http-mcast-02" title="Since draft-pardue-quic-http-mcast-02">
<t><list style="symbols">
  <t>No changes.</t>
</list></t>

</section>
<section anchor="since-draft-pardue-quic-http-mcast-01" title="Since draft-pardue-quic-http-mcast-01">

<t><list style="symbols">
  <t>Explicit guidance on maximum stream ID value permitted.</t>
  <t>Updated guidance on PING (and PONG) frame.</t>
  <t>Added a comparison table to appendix.</t>
  <t>Remove invalid use of trailing headers.</t>
  <t>Use the new HTTP/QUIC DATA frame.</t>
  <t>Prohibit APPLICATION CLOSE frame, and move GOAWAY frame to HTTP/QUIC section.</t>
  <t>Redefine server push to reflect core document changes.</t>
  <t>Remove default idle time out value.</t>
  <t>Clarify session parameter requirements (session-idle-timeout became mandatory).</t>
  <t>Update frame notation convention.</t>
</list></t>

</section>
<section anchor="since-draft-pardue-quic-http-mcast-00" title="Since draft-pardue-quic-http-mcast-00">

<t><list style="symbols">
  <t>Update references to QUIC WG I-Ds.</t>
  <t>Relax session leaving requirements language.</t>
  <t>Clarify handling of omitted session parameter advertisements.</t>
  <t>Rename “Idle” state to “Quiescent”.</t>
  <t>Add digest algorithm session parameter.</t>
  <t>Add signature algorithm session parameter.</t>
  <t>Add Initialization Vector session parameter.</t>
  <t>Replace COPT tag-value-pairs with TransportParameter values.</t>
  <t>Add example of an advertisement for a session with content authenticity and integrity.</t>
</list></t>

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIAPqKFmEAA+29e3fbRpYv+r8+Ba6y1o2UJhk9/IoynjmyJMc6sWS1JCfT
a9ZcCSJBEW2QYAOgZMX2+exnP6t2ASBF2U46M3e8enVskijUY9d+79/udrsr
VVplyU706m6aFFXyvorOi3hSDpMiOinyKu/nWbT26vz8ZD3Kb+DD8Syr0n5c
VtFf3x7urcRXV0VyA4/DL/gHR/7LQd6fxGMYfFDEw6o7jYvBLOn+Y5b2u6Oq
mnbH+NPuxg8rg7iCX33Y3z0/+LTSh39c58XdTpS8n66k02InqopZWW1tbPyw
sbWyslJW8WRwEWf5BB66S8qVaboT/QdMtROVeVEVybCEv92N+S8wiXE8naaT
6/9cWYln1Sgvdlai7koEf9JJuRO97kUnNDP6iCf8egZTsx8n4zjNdqIMP+d1
9LYe9Z7+r2v8vNfPxyvBmKe96EURD65mxZ0Z9TTtj+DZ8Ku8uN6JXrzYi06T
MomL/ij6f6P95CbJ8uk4mVT27QU/37uS5//X1VUf3t2bvQvfftaLXs2KsjKv
PovH5rMHvLOMx70RPmhfNsmLcVylNwnsJB11F89/h54TelpdRFC/JEWZ5pNo
m0nr++31VXo2oAP8oEyKNCnTyTDnwaPocFIlxSSpuvtIU0paaVINDWFtP6Jf
u9OmP135r2zSERxRWo7yqfuYd+oofZfUv6H92n0Xw5a4z4ocl5kM0iovVnQb
/nqyu/dzuA/8UfQqiQewBXv5eFokJa1+mBfm3uDzX20X/jGN+++6W5v3b8Ne
L/q5iMu0X9uGPaC0LCmjb1/M+u++rf+GNuQYXpel79t35GvueXSe9EeTPMuv
YRse8LrdXvSySCeDJMtqL9zN4knzO3rly7ifXOX5u7kH/Wq7C0ez233z8uXZ
wXl42LuT6M1wWCZVdPC+SiZ0zC8LeGX0Ug77++1oP67iLzxpupGG4GGguJvT
m7tDfF93Y4mzD/iE35yQV7iNWcAvVrrdbhRflVUR9+Ff56O0RL47wy+jcpr0
0yEsK4qjaZEP0yyJ8mFUjRKiefyMuQJwdfpUtkm4NnwUV9Ew7qdZWsF+lfSb
SnkKjER3CC5VPiv68HVNTB2eRLOSx5EX0rNTkBQR8Pi0KiPcMfwFTgAvTlKl
JbA3OLssvkuKHt1a+OAKp3AX3abVqDn9b0uQOZMqfk/DlMA+JzADeEEJK0nh
i3SSDPCNw7jA/0xxr2CKvO54APQFb4R/DpO4mhW4XUXiNm8Q3Y4S+HeFWwv/
m+RVNM2Bj1xlSY/3f5wOBlkC8vEbJJoiH8z6OCIeRxKNE1hzVOXR1Sx753dv
0a59+PBvpy/3Njc3tz59ki2knfZLQ04GJwwznUT5FHd0NsENgteMc5hsMhym
/RR+kd1FcNFSfAVQ+E2KL4RDLWH1SQdWhiSRAT0V8bWe1G0SZ7DNcLzJ+7Ss
9O3dIsmACGCDUQkAYQgSvsrzrORdnE4zmD8uu+xFu7NBmndv0nIGu1om10iN
8OQYrnLcgRsAZ13AOmZZXMAk8lk2iK6SSTJMgdyKfMx7Pc4HTK64ZeOUOHeP
97QfF0UaXyeOBpt7OI7vYMwIqamkU+R9dEuqDGPrkEBI3sfjaZbQHpzCHnSr
FLjHuSNZr5Sdok7Gh7T9+PHGp0+d6CVu5D7v9B1P5+0kHaRF0hfi8gOtvXz9
9vxAR3jydOsJjoC7eAwCq/umSHm7TmG4GKgsOnILWzt+c3qkTz5++gjeDZwk
v8UTBM1rBvxBbwXQ3N0UqRxIoEiAYRWJv78ZXzJc9aQfT8uZfsD72YuIkaRC
zEAz/XzSB25Y0k7BK25SkKkl/l7JSl4P92sABzlRajKv69i7dpsX77I8HnRg
6LGjHRwQvxlm+S2MCOQOpxzL7QcSmOF7bliHwTfoR3Tx84gI5HCCs4X3llWH
KckxxEFS9ov0ihhimeJpF/Qo3Rk+LFR9VU1Q6vL3rkFnvVb6I/aU3st2P3z4
f+AYf9jYgGOM1j58IKkiT3z6tD6PLX/44BQ/fo4EUe1hd4T9bDYQ1l0k01kB
vAsHgQnBgSJvlEkR943gqmQDvtKg8U6uE2JdZQ43wU0b/tJPBsQo15LedQ8/
GAGL1gPEV81KuZ76EpKNSJJJuY58pz8iRgD8FuiCX0UPXiWj+CYF1gg0AkcB
J8JMhfjRZDDNgShLQ/P4jG4yry4Bgs/SMYoX/LLs51OeCb8kRbJHhRDWRWy0
uAEmHb9Px7MxyxEUDoEoIRKtSSEgsRsgKSZm3MEeKRq8zahwflvKb+A29xOe
6CAdAu/Hf5ew0Oo2SSZMoSJs5BLQ7tfHZ6E0G4/jIi2BO8A6PnwAioBNSd93
zchd/tFdt0LmUQKHEL3AbZMcl5Hnwl5xmww1lMyN4VokJEGQEuB18LebNK5d
g3M6dNroEnhDF3d7kmTIYvJZBRpS9wqXNUySwRUMDrIAf5GWYy9UZVqwtqu7
lm3pgASt8McwHr2GDlbuCLwZ9wfHgZ3DGRQwznBWwHcFj5eo1HT8ADbmAEis
oBOCDR3gm+iugIiMo2sQSQXxz/gGLDJixX7Rg2Sa5XfEVpDFpChx4UvcpLg/
SoE6gR3Ra1WRxNkh7ZAAVf4IXAi4aTImaU4vPjy5eSIc/tkWsYZx/C4p6bbg
psA6Y9pvWC/8M0FWjPOnhwcpcLikSojpC0UMzKxXU2DGk0G5CjJ0wnwP1KFr
tClZVIDM5JUlg160D6PlLNGGzN7lcdxRJQtkv0RK+HAfOYXbrg5O0Isht0md
aMT3F9aRo1RAjqtXGZ4bL2DcE9ZGrmK8BAM3QUdPvA9AiiWz5t0Md59s5uhM
VSDmvE+fbT+D7cUTG8AgoCkwDyIlgfYUll3j6iXLhhL5rvy9y097pivykVfE
+h+KTTdSF0QuUZNjaDiHDPR7uPtXSN4klODU9UrBQGMkAKvulcqm4DdFF+go
AXVyWqVEpnj5CpmO3xrYZpgDkVKMTG2c825a9Y01b5rwVS7qtt9mfN/AqTlD
o1T2C1CKI5gX7RUtwO0cED9K9bK+P+WMFkMvw1WUMr4O2ccNhovi3kJyNo5G
QOFFjvczn5U6uko8FLtAwqBhgohiDhYwU3OF3bKsNuj0mLN9VcWfPXsCOhpN
7mxXP9z64ekjYa5JKyHGWemIG4fFqyHikfWWSFVqOH1WT4nEZJGzUH+UVcLE
yryf8lHRLZxmYKHBs7DICf86Skrk/WDV0+WJkY0qd4GdAapD1hRHV8ELnHEm
S6pzS69LxNFkNr5iEzCf1oynXnRIHJEkZzrl9ZEhKcw4YOolSNMsY5URWTCe
KxCyqnwisvBMUtkobzoEVDvI0dYrYe7ffBMd56w1wLT23NGXvKx3wKdgI4GH
rR69PTtf7fB/o+M39PfTAziD04N9/PvZq93Xr91f9Bdnr968fb3v/8afr8CT
e2+Ojg6O9/lh+DSqfXS0+7dV1lVX35ycH7453n296ti622aUY2guynZMkZ0P
WK9mJkiy/8XeSbT5SBjZ1ubmD0Cf/I9nm0iXaLVO+GX5BHgv/5O4NCoNsHvI
BGDrgRdVKZAqcfES+PIkQtHSqzsTiKMi7e7O1J57cfxSTk7UEXz9463tR3JX
ZtNBLOJcGO6jjcf4XZYDvTpjfvWbYpYlq8B21XFjBj0Tkn6KxCajbG2T3YOn
iU+iLgX2Am3cnOl0gkd5W9wn8P3Oysp30T9mOcy2W1YFXqfn0b8EH4B9kyS1
YXRy272t3pN/hSGq/B2odPoHhqAPlnp0VqTdUQ5cSR/VDxY9vdV7+q9E8ftk
cwmZm38Qw0mKsSo1BYmUQYPqaANUHO1EuxFNReUUDHKVkJ9Grh/ca2IIUTxH
PvZwvPavcHTktOiAqfE4NPtI5iZVjI41Fgf4l4bh1WGLYoBSAm4zqVN5i9bI
ZJKlw4TMeRg81olEZB8xQ0QKx+8md24XaAlmuThvUX/zwijFuK+o5sTvcBL4
wL0bw8PggHY78VMcwj8ILBk1pnvXiGPqhOqj8uefP647tbMkWbwm3tTD/R3a
ctRKK3SgsS5xz37wszBvONMKF4FecLDEQDknPYfObe4I3xgXCX11Jlraysou
f2CEY2B1kycJqIjoK5SHqsqkpeMqcUl60wS1XpHAasXd5vwio9IhYdCUp1ny
HmUY+dkyR/zAV5J4XBIjJIpBFYC0wn5xR2KVHBnAFq1qk0+SbpV34T+sPuAy
R+kUzE+Wr6jTd+qLLp1NMgAVfQZiE85cXG3AEZAaszv8TLWMtcMTdsqCPrCO
DJzVWLk+dFf2/JYe7oP4IH6ewHvcHogFVYmtA6os/FBUVvlsjJQnpHInuqYc
Ab4DGUIvelvKxSXTDlXzyh6ooTQQaPlt2Vw9Wq4z0CFhA4xbA1+nC9Zf34Da
wTwjVKLo/XVSggNAhXE2JaMd/tuFPZ1U6Nlgczd5L16HNd5MdhvDS6/zinW4
dXJN4Hnn10U8HYlO7z3l7k6AyUGkd8fsm+YyQmNshIbCGCg+hnWti/amzqI5
PqwWl7xxS1n/0iL//wgjjeTV9ZE0u+9zN1I8WvO2EtQSdqSQ25JtY2AD0xmr
y0NxtLi5k+5ym8BjcUl2Dd1d69HsKmND6kWCrO2mTOjy7OD8/PD4p7NLFi+w
ndEZeVX9KYhnWSY3IA+HKsFst9H3JGbh4iQpab3uTgDdkXsy5zX2Az5HN8zs
CrnRVBUjH+y0cldBfzTIE/agoJLMg9b847AyOp/7TQpv/YTuncMJEgI5VMXv
MMnt+bAHvbbUNT9GU3CuOyXX2NvOOadHnNOIeH0rFKzw6d9z1V2QE6KnZxCw
ZKY51HmiVb9JqxQNSkswskne6RjCYH/kdQ3RH3KbeMc33urYOBB42HY5tIqz
I6/yXbSqn3XY11kTIrgylQLIu6o7Ve7VLdRCFvixNaqW1Z2Egusjoioovm6e
1GpDCpcw/cDo+PCBdqarjg/6JXoYo2hXPSh6yef4TTomsEYj1p0oHWXiSgJM
Oiw3nM8JSUJtbqPREevM8dFxGA5qJXWS0MjBUq8SkcQhlVp0iOiMeN+KqpH9
u36WLNJH+KxJyiKvUiEbPgt6pjFkncpp9Bi/VCQr2QOacYX83uuZbu0FXvwM
X2r0P+HBJS6iRfsdZjN2EYqLNO47s6E5SJbnIImd/lD7jUY6aYpkZ6KxMcnS
d+iNhFMZxXCDAiEOogs56E2a3CqF92dFQV81Jmx8ni28J7RM4G3vJnAfmH54
vTyixlQa3g3HRcUXEeNNGuVET3BPMhiao6nIA8hZUfGuDEJrK3id83UNjI2K
Zv1kwN4MoEfYi2iUXsPauhiJzSJygDinTBJXeqX0DpGx9tcZyMs+mm7BKkcx
bU9wMLjmtKS4xB37p0mOoPrVg5Fexdmw64R0MmgOGGwuPvJylmV39z0jPJ/C
wxW6N2GhrLaK6VQfFLaxfSzaro6eXaG+/pBEV1ZO6CpLjJr0FVQQ5GgofELu
jYDt0C+RNwLr4TMSBWphXAT97hSc4lPM+0C27GcZzArl4bSvB36PaP68c/ZT
niu89f+4Pyt/6fo/f3H+BPtp/cuW77p/WfkY+T8f9eN/tZ/Wvmz7LvoI4zhy
i/wvPjaX+NF/11zpx3A+/6ITapvPv8z/Dsb5Wvujc53z5+N9P7hZ8IO/LPci
85m+rmWucC56PdzPWmfcHK3tTzA3Q3cfdqJvmjeDk6yerx61yzsm4NXoE4pN
LzcPrNq/sut+fpVcpxMJZyWGrmiYXrSrASP3QGg/lMD4SVfkvBH0jTlbgEPQ
JHL9uHA/G2SK3lDPoVClLC3TER2yNmRjFBi5SeTEC0p5Qyvba75uZYV95rA0
CpTdxFk6ELFmo6+k+xoJ3rqFoKMX6fV1UgQpGLyOlr0g3Z514biUOHX4RHON
FQUkMfCQeO/yov0MKeOcJCiJuJUTK6iOdv+GG0ZqglNrKtKW0HvXizwVoQe6
4Je4i8ESnucCtmAgA0n5yJJhRXL7TPQpfGGZXpOkHSVpwbK5knDcTeKyhlj+
u7dXSVx0ByhMgvQLvTrua4oJnjpNDmOuqED0K40xy46hkKPJYWA9HWAWEqwX
I4FrdZ0bv+3Kty5JBDVCHpFTW3hFsoiONbvYfpVNLlmNNFrLOL1m3SNaCzR/
dpW8xx0gDXGdE21id1mZePyxqVtUnp0j9lzyV9TPcvVL35K1d02hJH56mBZl
xR8ak4D+U5rDGc0qOhP1haiPx+vp1wUor5zbMbtiToJKXVnl01IlPrkHVNKL
560fu/CHW2DeYBAtF2XufcOBQBMe8Ko61rLBnSNylc8Gi5bIJ9myyl70Brkk
XgQ/tr8Fdils/jhNaT6zk4tmNaR5LNddyj6dMMVCWU1K0dlTTuFNFOey2SFi
fTTz8SSjgIOCgRXDcQn0PQ6KGDYG/8YR9LsGAyAneDxwUfW0qjGmI6X+lQPn
xkUWwbcicd7euTkBZt4dSsY0MXz1I/h9N04lF52ZUtoGWEXoeWpcSrF6ynBp
jlsFBpQxicVnglf4NpBxpbf4wPxlvmSMRXbCUfgYvR9unTHfOkmsvQIjvBEG
X5A5kZZ1r0LdBxAa4Cd+mz580+qA4KTQpstk3gwavo/miajjhj0MyzloO/Nc
jUE2hP8e7v8wvZ4VGmw5q8/C+49pFpjW6lZkk47IIDys+Zx5megku43vXIok
kUiWBhbvyLEQzVVGztqyKWilNf0gcNMajr5maC1kUcqSNFvAu9+8x4CuRMC+
KFeAZosUjUcX6EIY4Kty/b29XmTqx466i6ruwPGKym5U8I4PMUCDFVHolyYX
JW0NCIj0Gu8HRzQaCYkUARmJk489/sy2KM1owOmuMBx/YrLI2HdsEl47NRsU
hh8lmDGLHmdOpSDHnqTmiqgyOVPoxyB9IM9mlRPK4mmX5DShD3j7JJ/BQDVf
g91E1D0HN7HkRbVq5yZQxfGmgc1fvz8VSzwVnrm0s4foDS0/DnyOusrSZQLa
jMJZ5T7G0fOiJQjedgVBAEh2iCaQGgu/NawsewDMBfRw9tBzJhBmq7BSQmyC
nT0+HMFRflImvd+6q9+jJhlwxUOJekmco84Z08GnegaHI4iJD1i46+NjaBS4
sFG5+spW3RT2V1FsUDKNv+19SboKo/V9dGTpvtlrwVaO0arKaTxxcdO6VlMS
9dM1ZJEcPBq7DNuqqQ7tlqgXK337NUQcBtCcUckuDQgDK0ww21SkXO1ZCSGL
iN1PsMCADyUIkXJudZgJzknXcvRkQpijhyNE8+GM6kRq4VZHzHhaLuQnSczp
b0KR4UQ3n2xEmPYrHmH51TJzVpLgiBk9Yobm7KgrUc3H6ILGnD+XIjYEtTi6
uqso4U2CZsSm1QdLKj7+yAwKJvAs8Tfcbe+lJ/DLJpNCc4n+Ye8BbuLhEP2F
wcP+IWRX7kVkAWtaduDP/C2B+5Ulk+tqZLIdnFvy3l10+5SLl5KuCUq4wLdo
kgJDE3q3KWadGlhJUMtfBwrHxxO7hffsHTE6kvzBfHggoK4KWDq8xR9Sj7Pr
Cky579TE6TLTYz39oTNEVjx3lhN41p7TPWdS29WmZ/qr7Su5dFhtED3EEDtc
EmfrBauiTXcZ6Y3L0CKk2y8AUB0pV6irGeFDlRycYkvcbpI46xTteZyXzJuM
PLDBZoW4iNxWSRIksNZcKoyEq4WFFjl5PYD7JNmQCR9ERRpnaPtJei8oaBU8
WtbCbwlYNCgo6hKulC9Azv1r9N13u1RvWX6LyZ/Jznff+Qd9ksRaPYvy158c
jy/XxV0xzGbvRdKJs4P1TiyxfIfJyVp8yXo9fYfxfkl2dDlV2Z3wZc6KCCwI
M6UgHYnzEv+NP9jEgyuRDPCicDSqtPUFuNnXOSgXxO1nyLcqKmEYUJarMx7i
8LLoaaS1/CWfuoTxU073q2V0aMQLJWmQGZLlt11kW5P+nfn5j9Fm9/T8HEX2
Bv5FtzWoduEMZvGuaOJM2Ti8jiyb8sHTcYpxU158NQIBf825pFqC0rwYcwLZ
/BofyUa3Fuj89G5ySei24geuCg6lr2Z2OyVVhkr1eXee7is7GHzrTWugFbx4
jfuCITq4MTeJeGX4hkQ38F2O9qY/Mp+LbJgXJVQ4qxc1LTZqKTzbR5W/8vo7
xgdLUAoxQYksU9blXLoQjMg2R4rOgYJILJ3QjnOoPvZmVDTPrQv8J/AQIk+R
9CzK9kc14I7ZXpDs4OihZuVT8p+yijAH4YOLZIjdQB7Ltroik0tjMrM4ZEq0
OVDx4pwqwZt8yj9XpWhVRau9swafds9u+uuB5VM33nzp9kjC2IaUFyUfNFwb
8jprxdMlHuaYZsHVFeICklg1Flik1yORESY4XyY/uiz+QVLR0bHPSmLcgbXG
YsindXB+IDvHytozro4tPDLZYNyeeuqd2Q4ftMcFi7dbdahOywa0Kc8+ih/6
F9e46kEtF6/3sa1alWbcdS1lU78ZWhXGaWmTi6PTGPex5QrjhWqlM0568fkH
Q59mYRK1W1SXayDAib+bNavQZY8Ryd0Ji8Bh7vgKyDoyvueuuhfW/33ujfAw
wzjwt2GdXRujknKxwJdpGZYW3ie1+xbmBWI26qxSlaiR18FZKMBXhinmxshx
D+FnIzCG6TIphcy7UuEhpGWjGEP1hK3elilT4IutsT1TCxLwyvrwfJwmKzlm
5mfSHcFglCQ9ZDNn6+qqBK30egbUCAJIts0KL6JXJ9vE8tOlI/AFIcs4Amkv
XDISMJ+5VBqnTszzCzUdviIR0fDuoteYdqpVj/sVpdgNCp0iIWaECZ60Vega
RywC51dQT3tzx4Y1SjWkaWOBUrJliwEboQfD1B2lXt3RmVEKtd/ShSnr33gF
dY+TEI2GG2olf24F93MVOnFDNDW1VatpYN0UaBqrXDaV3qzawCTl66xzwqDL
F2xJN/bag+bTL1a2/nmKVQfVKhJhh7/M164a3LShXZUyIdSvvlC9Akrd4xme
4QxX9qweeI++FB5l87BNeqyxbsV53hDc0SUP16XhLr2t2xf36Ll5atX+djX0
9mj1HfmFRGJIyXHNbEeCQfgCynLALA72S9FxwDVg4ShWGSUlFHcqic5fnwUb
F50m17Cr8APy96Gjd+f7729vb3tpPIl7eXH9fexclOX3VVZ2/aWo/bP3flSN
s2/CD7uPTMywrjnghHNKdA1XyfnKzilhkkMlDVEr9QL1f+P9xkYH/y9aO377
+vXFr4fnry7ob/h/60I2P8NlOBAjdOVna5G2kQrd8i+mEBjFEAb8S8qyjQIt
4hVdejdxQRAr6i4aJe+7cDnzgZjQUpjsaxV1fnY36oRHC5lDb194PDgnqS/w
mASYM4I+fRNIl9RV1oyDNI4w3IGndIhqb5ylv/Et/oVsy5XWT6O1w1/WF53i
hFn0F59iemMOMb357DMEJrrUEZJ0gc2tHyUu5vc5SZjZ1z3IOYGhlcC/1DQr
63aVDwSVrlq0Btkkct1Hd0Foev2Pw6J2GCyCCcrC8EjIckooADxpFrt7tSkB
1a/IiSeGxScYqwbmBBItwvglKXiToMxGqs+SsFqmVpeo8+Aa/GR+ENWVR/gB
vpzQddBuOlidG7s4r5dCqabjQHaaU5NUnzjjpO8r9PEtLOXAd9Wp304uuAUa
Ppx7C1CXVtGJVZC55ECmEwQ/6YuW3v6CxVcrqBUsEVNoF7QeiZEd1RK9Pvz0
CVUp+fZM8y4aPzvrwA8V/yUKCjfDpBFfzul98DiHtgwzonk21EJv0YwqqwtE
00C6/wfoE3Yn6rcZ5nAuyYDNIK/JBVzZa0AG2RJI4Tbp2JUyVJKGSRV16gyK
sSAmzSlOicOTjbyWoWUAn7gyGqmUFOp04WR6q0M6O/EMfRy/v8DhLmS2lx4E
JDYQKQEgijokKCNVdoAnt9Qt9UmUX/We+h1vvbFBcqazsuohoXE6xhQlfJkD
vML9be5TRzaKz6YFTKaW2kQuIipg4YRWKniwCaW8g6XJdQi+FjIBpfiGQR6A
e79Lkmk3zsji9Skx3tPnv1/EQ+zGfT43weAe3mmCLlJ2UrqIveEih5jgJzpK
glTeMbmklIpI6Eis52vBZpgaan5Wut9xpGuwlAaQ3LsBHS7vqigJM+flTRIy
DSmxZIbS/dTV8Ae+ssD4m0cQtxzNNqp9kxq4yCaLp7gFa81MBE07JZJ+ncTN
qdDmzMRlUqYZlWhjSq9oMKRC8JWbSKX85d6b4+ODPdSnLvZevzk7kJrbKOV8
rVoSYBK/i16inX+KPFo5IZzsuy7W7HWRLj/N03ZizD8ZpJXARnHlfVeB1nSZ
7PCmQkot0S37IzhW9YnypcDhhibKTZEZtOZhqzOJm5U4iIuRuswzfC3hbWZB
yTKGk6+vi4TyyqQIbEiZAYIR0It+BfEEQ1LWRrsbnD3/rJpTDGIuIJBHZXX5
GHMYdwmqOBsCF8iZsJwUOFLwGc+QvrpAAIWLLO/H2b2/Al0mRxsej2DuL0E6
Xj5IQWRxq6fGFY5JrFitc4UGUhGfO1JRq7jwMRX0ykxQbURUFFYfC0nmfqhU
CanXyBNP0U6IcN6gILsZB1srUkCGBZaSmtshNglqoGo4eviaLwSLoHWbKrc7
hOY0GfFMUEiQ9XwsmleRlrUACeV1asabkH+NxDua7eeDD6CbkSPlTqEwmBjq
MqW+bfN9O0HgzMqCf4YomGsLOsrDGWL+6xhzFtszfow7kooSwvDIIApJOYxl
ccE98IgkGeCsdz2Hag/RtgRgGm+gdE0ZkTj2qSAbo1tbtswnbyjsMUoX/bLG
tTUXjwEPdADUtgnHSAIRPr0s5uT0FEx+Yr7CMs1dRA+BL3H2gDjOWIwHf5+V
jXtxxuwa85zOyeIlJiUeQMwur/9OMglRcGT2fUDusQ9bLctsZR3ELufyyVJ4
5LlGAmEb0N2M2Ijz8lTrJr/Mk4Xy0e6/X5ydnx7sHikGxmdb6M4sDxFERauP
J25HieDhCfpeF6D11ZIWntarLjrtZ4UBWx6VsjcymAQHPrb+vydbDUBE4T6a
38jp13W6C98LRL4/SzQ7jwHqpBq+MZkaXEaeJc52592Wnb548frN3s8H+6oB
cWg5YqhESWGu51QEqXCk+3qIXa45m3qXTPCtY18YislasOVACrnXcmEbg6F4
KNlWiPlVXb/bv8rDnH8FGwyG92yj6pqhndyc9xODzenGc1K0Tf1IB4vvHf5A
tBOTmFcGNOlZlNkQ4VYe/l29VMQvXEGgidvPDSEGMnH+5vxXl44NqurfLSEn
F2Rw+oT+NgG6YCe/jvxkbmfEZudLUyV3Pax6i+9lT+SpgJ6oJHZoi3Pjy80I
sYrmVuHl6xaRpQaeR5cqR1aPykG6O4siz4KSyv44rFFB5GtyXPCcNn/obW36
hAvRH7xe7/l807eE/m98N1AHubhM3RA6KtXD4DEpDYC5Fi3ZVhBtTpkArcaV
GbNVotkWHlS7nG+hTKJVf1xfgZPawZR1Gnr4JFg7i60MHwfiXDBXChgFjMm+
649w+4RhoozLtlpmT2qc66ThaukD1cyXHvrgbVyGCEYOinOrt12nRTjRNxg4
brXR+MjErrR43XUwQ8oI8gUqDA7gCdOW5827yIm0oyGXAyVdlbPra8yN1/wF
igehBjSVCI5/AdE873wfeBwuCK5R3ohBnbT4ppDNUvWpd6ObLBxPG5GHDRrk
AmY2ddButA2sg7jcPeSOXY+axZxwP8VFAfFd50VajcaO2w3oi26sX3xCmeHw
fTTxkdJDiBg0TaqtVrWZ5xvmNQfA375qJhbLAQ3mmZP3JqzGc4zcHHsGR9Nn
bHGwDS+bWyRee0xc0ggGcNZfiEjqI0p2GZonNIQQ/eHu8S5nrDb27xe+JYVL
XbgvbYGbIqXXuNXBPyRlwX7U3VxfrFDW5/8VWF+dEIzy2KARyilpvVFz0r2F
W7FDj575lqSEawUwzZG+0DrBO9ckN9Iw6H5yYlte3LVlaplsLDjCDL39Lryd
z6q+S9gjwO9+2qYwNjdijqJ4CkphFTT3aDkX86xBMg0DXwGIv6dedH7TTJHf
O/WS4eQDj9JSamRLMkF9pZdWw2TMwh1sL9YN3OQuL1Z1xOZpOf0CnfhugHBl
pKlqLSjpej2QkE7PR7XmJi7uak9Seyws1+6PEHNNa3sFuoMB4ydYhlFQ4oDD
9R8anSPko+gCH8FQZudRcTbMuDn3sDQTrZEywKlI6r2nJBEA6xlqXN9owiEz
Qpg29UzJVJOBWe4oyaZB2bVWmYhyKCzMKeK8FQ7eFmchHnlZBmVyWfRATW8N
c7m9nHGT+mw7AynILBtuKMpyCZWgVoi6U/1O4QksbWIEF8qO3zYq0WSp7roz
nAG1SmhKzVK/W1ZwBgnHC2RnWAjzdcSnm+zXlKAtgy4Soi2b+RDh2bLf5T0i
smWCXyH/qmUiJiGrjSyWkpW1+qfPFJcBkf2BErNl2Q8Rmq0n9WeWm61E8EWi
Mzi5z5Ce/yM8/0d4tgrPlrv1deTnnIGtCGXr9ESaq334JmjEt8Air8Gv+zY7
iMF99XeqSMgFdKTG0uCvrtIQM4euUMYTir/rLQZnUm9N7N7V3fqhFzoF7iv/
YN4ZVXYSzUJn0+ww8Milzs1ikldLrSg+bGvIt0zHPY4AhbUn1GZKU8rFQVxv
AVjrHijnC1/PDXEFkPIB0PHczojYPkszu7BFFQeY4J6O8wH5jowf83HTc2TR
e7jdgoseKmCXIAhKUKC4Eahdju4xwhOlGmKKMfI53N6kQMdjLzIRLNok32Ox
Mp0CCYrb44CZDFTj92qbPF5/TPBg7DoCGx7mKin2BPXKhVuByaB/n7G7K8Sl
d4GTqUH05WYZ2AYSEyspkNXUMBdEmT/16PUNEFOu/kJ2WVZI6xRQuzw5PP5J
mwAw/nw+NeyJ+GPyfprSMpoBtDmpcaBvn3AN/ln6W2L6A3NlJWdkcnElZk8U
+bRICTEO037wNwE6BDc8Mu91jvFHDU9kdIjpI3h6tbMO74+47a6kQRTMZuAj
MScxXKsjCcecW2yqtyDEorWTo/O36y6tnfDkWE8PoNhbe60Bh8ypCaE5n/MZ
dpDE3VjbPTrXrrdPHz2m9figB4KP9G2QA737AivJIbQqv40LjmpJzzBfz6fh
pQBrC4Vy0NONsRdc3eXJa1zrvkzp0bOtTXGa2483N38gCAcUwLaZgiWDlxQH
cFKDPuxycOCTKZpN9fD40jSOjaQlCec5yCjEKUcoZ0bUnTRiPrBbhp/qM6L+
SMc3ZKVUW9Fx18WJ5xhu53gqbS3iDAEgSb6GcNkmVfrt/gm1JbiGq2UC/Mxr
7JeC2nZ1516KxXOCTKHuZxU5GidI3gN7lFItMwUpdZFNPyb+gqEw2XBmOCXY
tgQbK71PKVJv3uHwe/jn3vQL+tBh6wXB2RA+VsI/kzCHBEnFV222/DysUXcN
UT1jZhXSj2Frca7ummUkGgkTrKk5UCquio4KaBzIv5le6XrPGCz0dib0tNcI
znnkXRJNnJ7h80aRPjzzZ8ioBlJUuFukZptTKwV/1ICWvUg40GvyUJBH1cCU
QVdKbMMJBn2SKGbJZS7cv0le1UErw98D0KjHBt2Ho+fhXNUS3VDY0Sk28ksJ
qmKKhbJptSCDFdP0hOAYVUUGl6urbUVEw8cB6REXPVUTsaLamRJ1Hk3nl1ru
Ip265xUYJlZdgtJpRNGYn0dDmka6MF9IO01TayclB75bbNImZvKSEZ1O7CFb
SOUm/JA+/CXRsGpkW6/6+dRqurWcmDi6hZfyNUbC2UNYN7pi98GFaRpFHdIK
uRxJJQvpk6prS6yaOHD0iD58+dnYaaSnLYGO4E1/LXBZtmyq0jT1+duiG1Lb
jJq0aSmXtpBWbO/dX92TG5H1uFthM5e2JjKde+b8GUfJYLGsuA+wDHvSl/ZK
VFAUIAhIolmD3CTBXUmtmSV3T/8aTJbrhDC/96vX0a+qabDOb5xfzA2Zk3RZ
CKJqiDYFmq4mYc75KcUSbMtOYybUnc7KkfQLMiuTuL4H29ObQc/4d9f4k+Tm
U/Yc7S3VGuxxNmdLaZXvYbxsLQHnO/ssFEk2JLkuSo5rAUxpmPu757uXaEia
pEz5UGPhNpnm1wCDHwfNciAogRnU4Slt2iSp8kgkyxhOnfIyXXqKLvcS3+vT
FHFSZkK1/EXFhq9tcT1RVKfK5S6Msag5OLdc7qDQik5wC7YCabkKLcHOiTJQ
JjlxDDdYUSDswmX40iM5m0YvtG14MjZLR9PU1Z9V18h63qXjz67TPLlOfScp
v3D+VjqAJQdkW3/vwqxQTOQIEpdqeaG1778sM9QzJNPgAXUbviGV//DTimul
il450O7G5ISxRYk+7cidDfN6cggza+Ben+7q0y2qXB735cvD40sS2z7tWbZa
dpeKr8zd0x+dHpwdnF8EPyVolVrrsgZwn+mbuD6/bMsdEqHD45KMEeXtt7ZZ
zGtp0NBAzrRRQFP/cMVcKweNtgKLxILpUK728L23wgAgziv3Kt0lp0ZrGSbj
nSaoCao8DC7AEgSvjeKm3jT+XJI+mN/4w+Ba+96aFEcERiOZjrUXLWwUgkxz
XD8P23g1qKrTgKXb+rb3LWoc0qAY1/sASMZQi+s9ULNMRtoLV5/3TQqkE3yk
AO7EaO1P27uxmmoMQZ7SlG2xv71uyam56O2Q+EzbPFjexuJj8jn3xwe/Xhha
PFQmfHpwfnh6UP+qlQuD3cIIlOh68iOf7J6/uthDxePg+KcDGZY+hKt88ubY
0jxFFMrcDNphkHLj1sLIpqYo36mkr3UpJuQ3AZhn27Ntx0RbCYDYFgRfFjha
vKeJTWot1PK4eGo/DaSxgdfA6CeNY/GIDtKyVge45Fz5C3+4mHVP/urL1pTO
gD2Xzj+92fRDuCiEZ1TeVvy2JFvxu++w53U8Jo5kqJuqPSdz7SEqYGN4/nme
kS2Y0jZfQMdg4CaKBYovt7juSb9+92yiRKxqNbuw8VDuHXPtYO9Y4Se3N58Q
/CR8pHc1SFtmJci54DDUN56KuOz78QVfOPBMF/l0atr22agtWXugtWKL1VQT
dFXOF9wHrKQ5uY4nNbIPmvwqxdg6I5m4ebGHsJNZd6ydjy9ruPzCCpw5ROI6
WLRhPgZz8uCNYIYSiZj20wNpv6MNSXFqE5lsYiUaDRtgOvpoYBXWGlyGpZIG
9Dysrv7ZV/h72FQTu2DMROkwq61SFwDcEekXNEVT1aIdPBVjgJEITHjbeN4m
edOtquqR9Pvk0vUMd4gs/vll7jVBUiTTWTHNtV5HmLcP+DDGsjTTqhkxBgtB
ejAFHjbNJXcRTSHDWnsnO1EJVqAOnLqebo0Gm9oer14qyQk017N0wLgqE7eR
HMbnbnl3rrY3CGzV0A9pc+OW/TA92B64ONtWV84VQX/B9OQTkpPh1zhlDsNH
fUxuAIXtmltmDRJkJTy13b2flzSP0KcF+lLZ5a5rqMZ8Dc28todwkV5j1s2+
voRYHryDo0cfvqlNYcW7L5uBnUDQzpuL2R3H+BxzsN55a5f6bQv5Gt2nq5y6
GrS0Wp5fTPhFqrUcTCG7FDq7LcamRxzBeeJDkT4koTS/ElroS29WnIg8+vDN
nJkwY3PoN0Fgw5KjrYS/CjuL7RACUa0PAXIl9cyvCZZah0HQcb5VwsnArzy6
+WlSFXfrnegX2HKS2B5ZsVM3jRTENpy33Iilp00E0WkxzPCz07+dnL9puCvg
3692j/fPXu3+fHCx/+b4QH0cC/wdtqK406Z+y4fnb34+OMZ/1NToTl2H7szR
1Tto3b85uTg7ON7HC9ppd6y4j33ZrTisRPXueJdyrfyL2df8PgyhL1wNsKCy
asnT+dwTdrd2R7hUp+ZHEOZnNAnDCOB+TSz49sC8Fr/UYEPJj3HSS1IUeWFD
MjQ9CchQ1KZ2P43Zr1wK06jQlP5+2yRSeXN5iWwqeVptiN8/m4pm9zskUpFH
gXLraqoV4+2VDl1ecn7QC940/tXUeNSTVBDjmurVXejam1zhOibGCqXMClgR
GuaiXLgeC+79mGf3kOQ+fIbSIbUIWvqFE6Kj01Rqni8HsCxHfXny9uzVxcnp
m6NDZgqvDnb3D07PxO62jnIwbxR3XiVYE7feYdC78AbdrWFS2Li1oMJSFqzL
rAhyo0Jz12RF1k4piYss5cTf1g6ItYw6WXVg4wZkJNWarUdX1s4OJhSTSk3o
LTJT0JX086753HUeI6qzPkZtXSZXta1rGS9DTwz40DkwpbN2NWRJ1/Zc3Wxp
EIQH6S2jf9R93Ez3J0DDZCz5i7Ry5q8ErK2DKxokwxhuRgdDeRgcZ21LNsTg
8+EVCjIc9SccfU8IPro0TQJLewEJgFyCOnUYE5ooAmMETKDjWMTT3lbv6XrH
d+wzDvHKHB7KcbpyhybOE9hVnIEvVlWTS0gPSqflCYhnKQnFnDrAoB+NyS+C
vFuM+CEVjDAVHcuFBtHf0deaAObCZETRvQ5Z5kpwtgsBQh6alShGcQtGyPyd
/1MhhIQ35GXNh9IR3z4HhnBwhmq9k2a0S4VldT727q1dbrzf2LzUjCXdrL3d
472D17Rfulm2QMIQd2D6oVF1he5EHwtyXYr1PFwKwyAUfm8Vh9VsIxMZ62/0
sDPRhwT4V9xILlWdzj7bNJ2/AQuiRouRBY0SJwOhv2KpI6uh4qvqKB4L5S16
JdUzQGgR2gpNdcrfZXZOm4jdJMh5cRurxzzB3G0szAdCHqeSOWW9jLB9Ni8A
YwGk2Awc5YifX9JFEo+S7Rp6awYEd3cSbu+7qAYIE4TkyGGnhlvKu8M1RTVI
Oa37v2iXygWpGZ2av5U5LqOxtStggXGinrBcdBQXsfWYWiRLj1QP2TN6yIdv
WtUQbvJsfidKkctoxVSbstbNE5MVT8DO1WtG/6BuRESZvrQKG6BpWFPv+70v
2yEY7PeUoozg3eijS/toKQ3uJvEY4exIbK8Tv341Gw7HhFHNuZW1mhgr1JoK
Pd2hWm+bTiPAw/7fspwVjI+x1tbRkBzfjl6wHbBEkNaD/pzlDD13KQfa0DdJ
CbYU2ZHFDRJJEnVtNYIMDFuz6Nz4XDlm+lcgm9Q6n2DX3N4q3Eqjg44fhnom
8eaHz2qXovreB27Mq2SSDFO5hHzDx8KkLAkoeTjA9tCHfu5Cw9Z0bUZ65x66
yillDlRqVWA5XS0STMExr4jvcEz4MiDQ1v5ET3pPTH+irW1OpHcpQ1ikN5Cg
n28or7NTris54fMmIe9HV3ZVehmqV9q8TwZUDwYXm8wqZ3QLQzH9UP25CN/8
3o3vu55LKEqXYiNLc8SgrRKTSSFFp5NZ0E+cHBbcMVPnNoNfZY2JL5gclw4z
kmdNcfnpze6vu39rNY3u1+y+IOehYeAcUOUGq8wstcm7HThkOG8enbFg9aSo
1jSVYMokGyUSqse0nYwaNcBcMH5SBCWgyItSqUshOpboiq8CqIUQWV3wfVMD
dEeMNe21WFMub46StXVCCMDVZW7gpibDkRsou3MeuJoIlPGkXKJyaIWS/Tq5
C5PIAvzVtEDRnkqNMpyi+BLpDR0T+68BRtE/GdC11nq6xW0i15EdnHUARdHJ
yKVO972MruOpK9fQeF/s5iSRXFmk/a3djzWQd5z7YVuZScNHh+i62WOyosZ4
i1QKOCZ2vTQCHdxxB3MixExIx6osdTAxoZ8EJCEKIw+ExgfZcpr4yehlRg11
at89Cai9YClBKq/BxiUewWK4tmTntuLVkpswS98lpHkS4DQfLqkxJHIVczpo
6gQjG1hnuRTKdTt0vrWvC6BurQwkq8JkvLvqLbqLrgCDG8QtWrBT780KjStO
xYOQW2znQiUJEgwGAZTn75wmBqy1qBz0K/ZKswQXJGvrDZWkb4QJpL3UnYyr
cA/Um0KMvryb9EdFPqHmb3n46tjiHbYsjQ1dd6VzxVckLGV7T2rbybFtqnTn
em69+akDmTMaga95lhFbdpddKG+GQ6pDpwz0Vg5RUxWkKp0fa+NIs0rm5O9Z
a+oFLoOf1E70wAhb5ina4C2eODChKiCsIBTHWAWYdaSFXi0Xyb5gH/eUl75G
oAFXyV0ueSh2CuvUNZHlCDrd0WB014gSTKgt+DQGbu3LXWrsQH7X5d9JdPPV
dhcn1H3z8uXZwTlV9Npt5rga9c3iX1zqOtogBzumxaOp4ynzTJQ0OKyCtBM4
Ezs/QeRrFL1qtwhOXQjvfsvU6nMiBSPsk+hKT9QpbutXMaqkJd0ZabhJkXJ8
xtcurJLJx/S3qhS7+/rkGCkQzqTTwN778IGjMjccM9UmNt+4YNJBLX63csDV
yMxlzLWSrE3ngw7LK9eSHlghtRxOqwN94o1e78w5xFKGuNx9fX72y97l+mem
dc91/pih5kBWtmR+f5maaMLusmgJvAfBdv9YLaAZalDLB61FTe6EbtGOCS40
orlZtuhuLf3yRkx26SXYqKx1zy0MxgYS7gEh1zlDcJB11+dUdV/Hd2jwaOvH
D9/Aje1m+KEvCF1Z2fVVkMu1UGc5qH2GwjZr6oKdmzeGBF5GpIEregO5NkpN
83OdKoU/eEcGdxnlYWgVZS3OK3crDE9g9Z8JmUnucmnBrdB1cRNT8vVwNhGP
GHXUrZTRuT2lF7vcagK98f3kMVrUQA1kzZzutB+HC3JE0hZVzDWtCatIrFtP
WnUJ1GADJypa9ZjLxlJQFVz07ZCwY5eHtZHJGsAW2rCfOTeHIHIDpd4leZZN
TTPnGLs3sj3MvlkXBYpt1ai3JjxjVw3Q7f9k0K3ybsIFVjUMPtN8WANrtT1h
GwWXqMElJ+vYVzgP1a/mc/p6/YnvezHpD5ScSy4amxg1ceC3Cu1mnT591gwv
Gcbz0vha0LXkPTfweu+msZGmmi0iqluNxjA5VfhbKWXBAciOs1rlHXCUhFmr
RT2NJtSOiGovwl7T+DZD1EB6yRjDqFTvVsiLZHgiAuxK3wlVUvHpIJ6DwkDU
3oRKC7VDYvcOOQgr7XUPx4Fn7W0H2XnGoxMCRP58O8LoHR2IOyW+dy2vlORg
6ZUhI3MBBOfY+isZl4QVZUIQV/lA0osNAJ51m6yTAYQVr5pfSz8EDle/HKiI
wGlfjxmehzJPLAK23CjnxmOvTKe5EWnpsfl8b2PxddVXD3oht3vQV6uHBO+9
m6lEUdBRPnHUYsCgaskQAsLn8PYwa6eBgPu1EWyD6GJKtRN/FynhdWG9kdZA
8zFfnz1CPKwel9QiF7JdZoRQw6aPW1QocHYtypqROQH6Hokdln4LxU6zgQdd
QpRDglD/MHHEga6Jh4KL+Aaok5+rmmBemGxMjn3s8NmchdiYcm+sfyxw4lTx
eEqCjo7CCwJRQmLUUfJZSTypGCcDslZi7HX7YFElwRe7+Q1f5jKSqB0krx4A
YV2IHWP3oMP8ToKrfZ4suw67+71+fANr5jw5B6NW1kAtfHUbUmkiDg58rUtR
aoZP74Jd1QapCl0HVzNFFCkP3caTvknujNfEIXU6N4iwF83qZ+rmwVt+TXTK
o5YENVZWcwKSxAt9INxPC0PNyjEbSHXwX+192fJ2G70KZGud/BqewC+Qm3nh
Qu6kFHBYxp8TR9ro7w+Tp35L6B6VrSvhs5F3WbDMkBZ227ZLWLQoQGgmoLFC
vdRqClCb/3lNdUzTNA+Fis6Go7vqNE/RjFjLC3JXrc/TrGj3JNQWCHGnETTf
Woukrdeh81hbDrM3XTNBryd3EOuf4e/S9rhqeCZXSbtcvyJYiPpmRGsuirpg
T9ddUVg/L3hlEjmrLbJluHAnwSzRhEveVxUnZPrBHAdl66FJxKz+uiq/psIs
23Y1uBPMgvwGizR0TY0N1YoPGqaRobumIHWsE25fk1m57LQ6y1qOssT5YWS6
qa9yJSjMGqZZfKedZNjDYFSRhdRxuU/VZHK97NVSn7FCLga0NDeS7yuIFAvK
dVlrvg5Fn0zeL0jyYixmni8cYedbf5T032mB6RDOfoSdX6SFMeEtOs89JdGY
AZCUvAPZLC4NOmDM3/mAmzG7qBlBocaP9w4rcpwids9xBOpl3Una2quAHJYc
TFzu6F542cwqV2CHdpZcpuXWbMa4UmhWKzkZUy4Y2ztxVRcAX2ARtCJ6fx4y
93Kqf0Mc/b7aP8FrDhg2u2YA9MOvPi0g2CJpMASTFiWeC9H/NS8jsuN3ancx
mZYeXBLU8ncEy+i6XdX8aBo26zDwESfvo86eTPrF3ZQrCjRPzvdL8tlQiU9S
Ed018NKRVNSxUCRibMs97loU1jpIscmLwQj4uXAK3YxBooNF70AlJGcrhbLq
ZYCu4G1l5UViOpD5ij5FrHG6m4uC5fXUlXJOCn0tfNFSBNmUB6LmcRkQiuXZ
tDIvlxLnMs/a6pytjJQ8b2Sh+NqkdHBWPsjm05mQ2CJXvVskAR/0+38f9Mq/
8QdbGp14mReE+XmAvku4FIXkMs6xhXaBLxCNwfXDq8IFQfMGcW2hCYCJcW6d
nuKDW5o3eZsWBiQ4PBtYjUSvor9ubG+xMDo8OH/5rbQ9+jUvSGj9hOdNpswI
OESiSXpCquixWROXzTolN7w82JNp+oSOGXPyJjx+S8mSlpcAe447voDJAOmH
dUuBq9GGFGPy/VOiwX37icowJUzXPQ5cyTLrU7JK5WhS9jwvxZig7nNk9wep
ES6hmCjjrUR1Tzmq++GbWviWuCLxOY8XF/N7g1QHRqJqCR3PW2VHEPMtrIfF
OpZF0Zu4N6BcOdqcb/EfqLTk2UBUILcrNHjuB8azl9SBdMLnwEuam20aGp+a
XyQr40dTtuM0oYHUZV5wULeiQXNxB5HWzen1aKyAuqs52nAaXLrHoM+aKyC2
DhtBpJ5ISw5nugvLFRC9S6/FOy94kBU1T0/ml1MFiMnX0GVydRSH2x1sA/Et
lEY+g/3+LIsw44GVyyZthlXbKytvS+fMMc6txkmhZZYT5lGUaLqubD215lOz
x6V8bgPHFCdycBrNfX57+hrL3hjzFITD38k3XXAeo2g+zo4hx21oksurG54N
TiuX7FCeHVNHUPXNk2L60t4U1svnA0+LKRvVh6w0MYa49LkjLsu/TrVCUI7D
uaDWLEtKL4GePtt+RgIHpf15DUfuRNzYqpgh2jB90hUCBk7zljhmPykop6Wf
FqDJSG/DTtjnQngN/IqUwCkJVn2VCSSQSk2VAoEgvQINGN27eTCaZn9dz2L4
cZVobDF8Vlp/StIqGrUk2ym4EAD54ekm8LNckjXvQAS+N0k699CkUqALAMg+
1fI+qFgVqCrLjNnIVrNzhDqtmdykONvm+/GWHQ7rLyM9J6/F8HeUVV3SCM7O
WtMaum0LMcQrWveWfK3H5AK/iHKl0Csyx4cka9Zd46LgCkwNdCuC8ru18QQh
73lEXvpVYnKiKTvBTTK4/7HnsuGKmc85RB/Ds02kR5n3nBGVb9shSV8+URUp
ADRVxYnQTF3GdGuJdF3HMlWytiDc1HFJmm8jhO+HmngchmgNs5EUOenp9gai
vtsEptH2eFU0OGN2GvnC2joPbB4UOTMkGGbiLvBol37Z5dwn1yQrqN2h5Cgz
DkGHsy3jewb5N3J3I9uc5/z1mQYiXAlbwuuw41J3AkHDV7SxZpVj7Reqie9j
ipaDtdCjdfBWjQwu1tBhg6ODQVo5pCXU0qOTjFrDs84dheXPGlGczq6cGUm8
kR1nqmW3uG2oR2va1h9BvG4dHpRqu3BieF6yPUQ/YzCEb7iMXWjgLRUGcC3W
hJ5J3mMr2k7jPS5tqG3AmdcCmA4EJbA2UdpDXaGbujt3ydaTO0vjRKvd1Tk+
WB5M9FKRe54WeqjeqkXeEVQE4KGDWWJwEcakUG88qd02n1qps4Ddgp+tUkhg
ToqgdjpBl5iBucJyoXDZvEyq4m9bKZfdad7hRHCeFq4ueARoKDw7P537doGj
PzM0hU0GmqYa4WVkVuEjlVUtgTJ0Y43T61HlCUYcMUJ98EIPOdId5jmQo4+3
YOgmi0GGKpKBwKTxTqxW+btksqqim5vQBIAS272ttiKiA7dN2v4JK61mBXCV
AfeGIEVKwlRpYc+3R+rTvuu2AYPX8lXPNF8V2EWNybBEQFtsBlrTWJHqB3Y0
aZqOWRTUIQQBPULpcXhCYWNT9MlWpFc6WE5ordc+cT529ziptXa2f6JdSh49
fvKEi+z5gV07QfcE/3brh6ePxI+hP2fEoHB4/vH21pNNKRpHBbWgHMa0T3CR
gwR1L9pwjmJoYKrhmDT5d90hGEuTQdClWmtIccmnCWishPxl2mK7JZ+euyVv
P37MLa8PJ4xFEKtXuF63WIsAWxeb7Q7tjo0IF13wszSr2NQQN7KJ5WjdZ8nB
ae6Dp2o9Y6rraTsNxRcigb7k+sT57k6+IV9DP7CZ2FrRnfZrrfu+d2TIHhQC
2ppl7wTOzijZ37vCFrC51EGUKbzopVhAYYlfarXiuNY10ydnW2AW2VCpNtbd
kc/RUmu3g8Taw+KTIqhjVsuMozXsg0nFcU2SRXpHXGEwmHga107W/IZyHFhC
Oy8zlPAxeDSuI2IFXzsILSqprJw1BBxacGNhARiPzyPqE3F2NwZaKtq33HkV
JhymMPn3YQZ8bTt1lxv7zxaxrNnq4oFpurhG9A85itAkD0hD+4DUbPuKS9RF
NbMwRUj6vp5C3gLCvj+i6ulmEQXiOnCqwlx1P2jeYECrAq+BsqCm1u1MH9LZ
2qoLrOmh6C8M4aFOXCOpdkPwr2+klwb/XjCNQVzVB/BrWjs7O1Lj4tGTjaeI
FmYCTC4CoUwLcXwad/vrJfuUcyeK8ecFXWlJkQjXbRud4jrc2bh2D3qlbCE7
7Eek+ZE8jsWJJvRK0lOosVwUha+MnkezIu2O8rL6McKmR6KteOCbrd5ThisR
fa91mOebP2z1NkDp2SRyXAx56gClmAJh/sJMwjENDKurwfDk6xquBK1l4Vok
DMzAVgmCNuR9gZHxpRzcBJbCL65Wzf/MozNwIs+AVC9fwn7i3lgnZi1jZ6IW
lCpBZJhQSQ3pWXXIK3bgVkWOSL+tqORaNVCLSgxAtKdZiakq4mFqDB1zBQ9B
hRPvbLSwLaXP0h6XIJxRCYJezD5VpCygYC5c6FLhwj30yx5nfi6odxDv+4KK
h150aV906dRy8ghSIu7QJ0SU+o1304IJHy7wdOl201VWdv1m1f4p2a7hh91H
6zu1W2dnD3fu0XePolcH/75/+FNwt4RsXemM3+tgvzbeb253ENYnWruEhV3s
HpxdbG49u/hp7+gC2PXW4yeX6y3vfb65vbHJlkAAxUbBY4WVdy6O2oY3uijO
rWzRtl0ONPnOUdO75O4ecoJfPISKMJicXxfxFL7CiLIhpfnu7jpHxOeeR9+1
nIf/wfNH8WC4mcRXP/S34u2nw8Hy+whPf8H2CdEKOGr6G5s7vySYfOv2Nb25
Z1vTm4ffzfZXrh3+sv5Zu5zeLN7k9Ob5o8FV8viH7bh/9Wiw+fjp03jw5Cp+
Ouhvbz774dn2o2T5PU9vvmDLG863Rr+v2mZrF1oW6e5nD9jyecLSu1zqUty9
Zc6uzmclOvgm8o+N908eg+7+PsZ27uM4W2+M//zJ4+X33bZOW7D/vnGaq0Dn
RKtg8vf1C2vtCyZ2yK22NkXZgC0SCeAl/S1h31VsNxAm/mJ3/8XBwUsxgvD/
+OXVF759SEip1KFR31+nNbCbzxl/PTphrPYmwZmWJPfoky2PPIAMLRq8Iscj
cl+aZaDkIPp+ucjsmk+kfjZIrkCrh+fRj5z2hgaLGX9JIo7xYLvjdDKr2sHs
ZfoLZvL8ycbnELYfYCkSb3ST+QbBqVld3zMAiXro4/i9Rz6sHBrifWrYvMfu
OXzVDIULCZykz7bwQ0bcZsRZpaVP5XHASEsTxrzZWuKYTVAFg23d3upyU0ki
liXpgyx7hM7kfpdgpG9uRWvK5MwqNF3HTwfr3HmtIW71PXN/vrm1PDnNG2QB
Sc3r1h3yk5MkfsdN+U5jo8a73hb3kFHYCONBxIOuasJCUSqKr6+L5Jp82YIQ
TD1LKBJDuBPk+MFUTTkKzS1ZioTCmVrCucKciWlCRdDAUZZmKDgio/noNB8/
3oje4XDfl+20EE7iOfwe/ixPBfW2I3PPPvyhYySczwzHIjmu7rg52dgn4d5z
6vWfP0Bi1CsHl7Pl6i+8154zIRbNDWiuXjBsi8CyK79iEWOdBuvLACqkyNDS
JNfYPVg1GHBdsODmvOK5fL08kTX3ei6ZNcjGacYuG7xJay053/cpKc0nHkBx
LZnpyxFdy2sfSnct+1CntwenxzeUpuaPHkxXbXvUIK2WFz0vyrhbjuIHEVjr
vs7XjFrIRcnM4dCUjrpMV4jFROV/uCQt+WpEH2xmoJNpXnF2fna3HGX5d1+a
zm9KVUJKTl2ih02U0E3WE5LN3O44b9/WVm973aTwOnhcm8YVTrIXHWA7ZFhO
4Yr4aNkSBBR1njwnEidX/3ZL67iOZgjkU0ljpbX1ohe5BONxIM2X4BALEgLY
l12CFCVXakDtfusi/+d5tP/Xt2/OD/DbrpsHm+sr0fw/3/1HtNpZbXsq+k8Z
Ul/a+AG8FD/GBcAoz3kUXsJ/uofw2+APefLY+v6x9UzhCfc0jxY8/Z0++0Z3
tG0QenBZxfc2N5va2OXnqxsbPzzqbAw2Bs+HGxury19zS+Rzb7dt4oLpCg42
Z0/AhjkbZ+5Vjm0vB7ooscfs5jZ+2gqTlDEZHQPTWVjo6UIhI2wx0Cxr8c8q
Xm1zTS1IP58eVE3D5drmTlKyCtxItVAwy9SVpPpySTc5A1LsQIfxfDQXFt9D
GaaCuqTvhfG6uFOThPAUwfrs5kPuA10l/dEkz3Iu+bO8LsSyplr/mNsurNsS
q0XhRYMpjTZ4PYvs25Lr5noEUU9Bdo4BcZdLOzPp94YHdyfJMG5X+gEx1Sos
CHQLRo9LNOGO8glmx8GXKyt7sml+AZwKwukwRX+UYp0PJRvhuWgnUXOevjdL
WMgEs42lXoda+Vg4rOgl13OPXcdtn3UzBysvTMV0PdQVB6AJ85Bf0cLmTk8L
zTE53eWWqfiizKC+1FKNcwGSJ3eWgQ2ytfTpBG9sxeAnA6oBM0VpksBKm9ih
vBrZd7/b2PQDJUx6A5THM0BhlvskUDgEzDSgaCuuIEvigqZOSSS8SLeaXDoL
UVg7qAy8zpPlalK1yEy7pXsasfeAaDzElHc4XrKFbaQnqT9Ptx4/+/Qpos2U
u2j6/kkU0CEBc99PhDxAv3tJmRWkVzR3nx0wBs1fxoVnPU8B2imJtol/SBp3
rdaR6H4MT1w7FCJemGISOMh9pOFZWTZqZ+vFk9Trgh9u3xoKjBYuO2EggUqt
xfISTjvAsKr4Oi6uk27ZjzNBsfwpxncIljmXE2VETSvzUB0xOWQ2zXwbSN/P
r95Loef8KwFAfK1tluTNOcRIKdKaeGkKP0KixaNj5HCrVFKpYsckqh3+dHSi
WWPbT58g6RTR0et9/ezZ5obkuOFFncbXDh1ISiM5/9PBqgBVgOSjzjeDJJlS
xRK88xoTg7TD6iiFNQArvIuukwnWtGR09wYuQSae5JO7cVq6m8pIE0Of9clh
ZpcjQtXs2stU8VCxmoIODDkrUK7EOajSws2Xe3jLe3WCWPoZ1rsCKwTehmi5
+fW1EyY6Si96pTgOdOdvpY0o8/ZbFJSYu0/nTwVHmhSHgHQFvFVFFabzIR92
3WjLAMgfjAskJUqzEqwAwoyCW8dIy2ml2XCIzkV94IlKrgPC7Svhwr+bW+N6
yuIFxL8B8VA6SFJQfiqJFXJgop4OihXeDw3vj2SZUmmz4tJFaRrSp1pTvIjp
Dn0zOyMJcFmG6ikHg87VtPP1kEGEEiSMSqoqaAk4O8RV4osh110P+Qr+m1AW
SQY2UZWOqTqa3cy4tLCOs9aDE//aRf3AALe0pS21aXc+KbzeQ4K7JpV5vbC2
o/2gfeKRqRZmUsTFO2i/89vcqoGjJJu2slzMWzIP/mgyWrDetKHQqh5Lp6kF
4wwO0o5twOgiHkLE/CrAwPq0/qNq2zlnkJJosuWANgTG1I+t64dUZmE6MpB6
ERPQCkE5WnTRtfltUKV2uR1ldV1VPk+gMLxPkz5yKlZY4l92UYR9miMdwgRV
W5Pv8EYo1S5WFd9by3yptVSsXAT2YHUqRwLKPUxDB3ufWjNo6wxxdRy7Hsnj
dDDIklUpKMQr6BuCcDWijOgMEuT3JM84OVrmQy8AHS2Vioqvl0LXsonNJGfm
VfDSAz/7OizznCh6+1mSCwVxaXKGd/cANQ4wpF5qmXKt7YzLEbmRHLyXmQMx
G5w4a4SMcsjFo/MbT24FFXFcJxnNvYhO6yq9Nmfbamt24HCWgQ0dSU8hZ9pr
Gts0BxMbDSIOHHGXEf1wt8m7eXCtgiwr9AjAmeETettNv7AhHkgIS54vcJ6d
M1ga2XqEpk+751QprteGs0oxku7hHpDZH4YBx7KfTOIizUXQk0D0MxxJ6rcz
eGktpD+O0UcLLPROoYtJZjtpVsrW1JKUJ5Jcfo2MYOKLHxB4ADYORHoJv22J
almjE+hGZV46GWItABaqC/zAEjmmQRosG61oNbCs8MsIRmtFplvA/UOjwOnr
Ku/aJFGL6oUpygyAUjZUBhrK+ePCQaTMlA4Blckj60vxkCziLlDPgBosOm/W
c0KvkC6FM5ZPGSppl7ld0LLM9TSxHbYN7hgo3ggFUIeKYtdFmY7TLC7gb7gF
vTYvRGiW4G6LMsZOBdXE6jtkgVnYtc26rTM7eCIeHKIYdNQx0MHJwpd0lcns
oamHPdGX4UOaedqkAusG4PJe6efNnnB549pViJckGFamgGNdV+f8IKQ3+oN1
LSgYMECitwVW+muDnvBkhA8eCbzSfpIlZChyh565efRcysk5CfhK4O/0qpaW
PdYpQBNQKKeBvCuwEVDZBC1zoKQODDjruWlZ0Iugua8DS+DK85iJxrqFBIfQ
JDk3BqJCeEY8bPipFkpV8gLk5BGcTYjV/YhkgXA44i5Sibk2tH5r3gHnYmJo
ZJy8dpP000ewRanLcgAerC8oC2M4bWpjqgyK+PAwZjP3Cjk/iZ9GEU/okKYL
xrScMsUaYSTWlYLXVS1FLHiM1zDvidT45mUXtnKg+RlwmJOUFV+xJln4vp34
W/HS9/vmflJl2Nz43j53/oJUrsSJXYUNsWUgpQJJLVVvnvGY0gPq6Y5cMMfD
c9o2i5ZbzJ2YBip4MDALeJ1xDIvB/UCftO4giMt3MFY+zxai7gvOureDd5yD
sdkyvd5Aoq6HfYnVQaqCsWBc/W29S4Y7wVwDBbILuGZyoTjqsOTJYpbNjPk2
ROg2W1ioL2fjnM6N0vTWeAdT6rFoKSfmLuzDFOKBq1AHmgddpou3hWse6iIe
+Jp2BhBPrlc163huAxo7CbwCBLV2VVCfIFDWE3GY1CMO7OMdaoNd5+SNfpql
yKAnQiJOkwl8mW/3T6IXmJRxQk5fDFGwu+3ZxrPHQhVsGLmu7CTngcGSs4yk
vFRpBBBWCwNFukTLagZme420K/NsJjqP1J/qwwSMgqDNYNW883UdNSSnMwJ7
ZsQMYFFycsStVva9hz6y9YMBz3tonx/VzdCGuI1dZwZ0/19fs+dLHfJe018T
ECg8sCuSsx1s3T6ZMPDabCL/WOe0wwzdwUBw01nmHJO2klUBUJCzq6Qs/Ubg
6kk15uo/i8fUsnJ3SdUzyNZKXjjbcg4Pa7xxIpEtbxKoMipS0KWKUvNkqeI2
sRZjELW6vGr5Kw2RESuSRuDQGgxEybJeP1FypRu4wNBKdaZ4AT2MMczrStCv
RALWqPDQgBS9BnLF1Z0vIjLrmKAsBn4I34R+UkM60j/T6L8sfXABGDxhVABC
Ypr4pjPWs8+NT+fZrA20xbGPZuDMzvdOqE9jXVcw3gRhEHGGjkwGuIQbXEqm
qsu4Jd6Zsg0kL3Gj2bBUOKP8ighUZnN2fCgJ60FNVMwVUUTvrxI4054g6gg8
TSjL2166HNqrNwEdcKPefzo29OJS4EMPslxnjAF3GjpfU0BYYo5Bpc1Gxb7g
GCjLwL4P/zhfMuk2vDccZvCG5GTgVqiRM7hqOWl0jG6hSBdGYrX52ETNmRWI
NpY5VhNgMBl3fVwnd7SGVImW8yPKs3FCUq1zglW8U1Reo3dTt1XkhpWUOMr2
CHAjuvUKdDxXzFOvpMzZ7pheKcqCRuHNvRETkmck5CREEnucT25LYrijoAnH
0d7+8Xoncp2Nfea181wZnwVc2YKTrxF02HnQnTEraldstIqaoSt7schqCUyF
QENbQ/8E5xs4rVF2pKlbwubvNvQsk1YiDroldKw5XhuDBH/UIstEf0kGrlrd
eL2UPWLIKcEeUQIqgh5B1Dr1omfUwxU2De4Ea9c+lSwkzo7vvqIetH5eStoA
F67q0aMqhF4nQiwhTJZa+g/LuBD2qQFrJSLujPFpPnzTAHuqZRH1Cyz9LSmY
eRuiSqmvKg2HtmDLC4Gy5JqvNvuCuVkfNwGw/Ir2y1Wf3Qd3L1aYJNh7C5Ml
5M3IUgLM42rAHFIAMB7yLAZlvQz1gbg+EjKgFTBRsoktHWZxnYcnfqmUIqZT
3YG/70QvQvANIgg20OdtFY5RPzdyOfQTHnLj/ZNn8H/b2/i3/WiNlriOj51Z
LZl/HJxrp44wICX1nNPogL5iWy0XKRYKGa1ijlUUd0tiqlRB6bfcafZaqbVZ
RT2HGkvsqBpQY7mAHE3htv5o9RVYlwU2jufcwKGd5xoeyLqbjU8Z1PLm1Tnk
RqGG5WqfXU4fmrmcxDj/C0mcj7PppGtOjdKcv3HAEJiXgqS74ieMSFM7Kzs1
XIGVlRp5tBFHG4LEp2ZNe8vLbInz8q/qu+F/Tu5aRsWcz6UHw5JoGa214LZl
/PRm+eHTGx29Xt2atA3t69YesPOmnHN+cePCl/kiuc95rS2x4wkcSQnSni9f
U0uqjebmVWMtP5m5VXsyobAsq2UKYYXP8i82RUHtNUEt76qXeSz/tmaByNz6
kLbzbqb+P+C42+oGamUDLe90PGr5N4U5zN1ul9zI1BY0RJ8vWRflALgEX7CN
trRjmLyrpbAJR08ldizw+M7LwMGF+/28IJ+p6+QE5DQ2TAHLsRp1or0RKHbR
SZ6jobJXxOl1dI4g1Cz+98E4HkS/xoKO+GviG0pcI/lg+zCYx/koH4MycQbz
HYBVyPruUXw9AYPn1wSh97LZZGBWgukr+Gwt1k9ApQdsNpUisBlzMH2vhmip
dlW5bOxeu9EYTCiUhmsC7jRwea4tQGQSMVCle70XQLrUgVx0ro7LBPMQzVPr
MsoR5v+UDgOamoZOqmB5iu1bT9+ox5XD4LjuYBhfODy5eUSKfke0MlGCBi68
KfDTzZwndGQ+frr9NGgI8OQJJhcGAroNucliDK6shDu2CIvLwAlKDeXccDZ7
AnQVW9uIKbSBKRIT9qhsbWxseOTHGuiRgyBio1hff7iPiuDmE8Q62NzwLZWC
YnGMZU3Qjsd6crDrwH5E22Zzw9irYkjfXyjsXuGLScUFyl3qEbMeh5bSUp6u
3wSvc5MxL2FeKp0hEto1WSnqgbQgwVLzITrhjiuYAY37+arb0x3cy9Uf6zhO
q24XV390TxowiM2NH+cV0/vfzy+RhqdrNbObXDK7POnx+fsymQMXBtfuRpED
qiMF7UtIFa7ak+g6y6/Q7dElH9dgafodDreTnZ3Nre1HyxEwfLm5M7h6Bs/8
dyJhR8AG2Hb3YHf/4ZhGZuc4Qqmz1bKzw18cuNhXuS3/4Y/wP+ddGHNqf+SV
8Y82IJ5+bAUs8g8shbTzNS5kp6W7Nx6Tbb36P9fz/5/X05GGSYcttdzWDdQo
kMcuIlobxD4dKWr2AwbB8pYx24qjm8P6Suj/4SRfwkn8j+dBGfx4byW6xcxx
PjCjpDtoFDUJ1Ef4EA3deYI1V2tK7ShdEo1gHLvWmSsrTjvnUDmmD7U3rYDn
6/04nZkn0RfJlcNq9AnVvQxc28gs779zDcA1qO+2QU2eJqfF0veA0S7oqAG0
+3/cn5UdriXYiX46OF/Z4cZKOxGhaazswLaMdqLvMV5Sfi8b2KveVys7UoRX
3e3oxqI/0Q680t6jo/Z27s6xgwx3JeyGsQNMzX+GbsedCD2j308zMChXsOHW
TvSySDvwbPS/weba2th8Cs/sbOD/op+Ozltns797vqvtQsQ4RU4I7xLsLi5I
ZJRnlzEn973Xqx9JS1ebB5ySdkN1Qce21ivyqqIlpYncGEEDHakRuzzlHiXa
WMbjY2veuGuSwqIGU8W+LSWHXSqCJy7jUleL0c1gp6pRvY+9vF8W33XzCBtS
6dvlPuUaiOOal8f6hlvqNNavON2m5JyJfxJpk529wxN7vtH97kto/clCWrdv
ija6j374/o+8CY8/7yKQyG1XAfVC3EP7/TYlQTugSrIbdWb1TUtMn9cahTXL
MNoLo/559HQ/+fBqXcPlWkvbP5KRsjjfUf3r+X6a/PWH34an8f7gbjfNzn/Z
uxm/SE5m74/Gf3nxpH+c90/+8te94vjsH/nz35ELK+f9ikT4z2bAf1q+267D
//e9np/B7j/zvv7hwuCPus1fX5L8KSXIXGNU31wmGGyi/BsN9CtbUNvevduV
Qsl0m72yfYVMRSUv+CtrmtYmrcVRDB+vrQLP24f2YFqIZH04uPTxG3zN29PX
2j8sC06aQlfUZIzsf1POWo2SRknCt5iEld4g78NfK0PkLAp1BaTcAVV7rS/k
A+bixa3L8vVbtKfCKS5p+y+JN1xGa/ZcOKtunWjgNgHuKxWFl8JX9FHHPC5d
NXmZzAaI4EkD/Z4cym0OZSEcDp6vKgai+dX33HGLN75nvuhNk/Fqh65gmyHO
30jV0fPVNVlPVzYmktlHfnIymJvV89Wjn/66d/TyPH45reKjrZej69/+9z+2
0h92473R7OX+q79Pn/yU/vsv1enk8NmLcnf1YRz2QQfd0VPuPPgEGawaE9Jn
pa1ao6eVdfheMXSL/8uoZn8yEkK5oH7ANnJ6u3f04vr9k/7s9vy3641ft374
7fhtET97PzwqD/pX28XL3e2/tZPRHAn1dVXML1QtRRSo5qgNVZdQOdfn6JWx
UemkYMZrkaTjmQnM0fBcA5d75edDxeZuTVzW3/SVRd9/N6H3hyq/fzZGQRP8
QyTOHydSOv4q0Tg1U25ZGfNfy5z4kxGWD2B4SRQFe/dnkEvR2Ww8jrnfmQY4
HEq/ZvLXETVNDMU80y15qC4mDmPngZWPPuNY+rFG0UdX0kWjfqxHh7Wm4uPK
x51u48+yn5lvcRYMMST9CaiPcwlv1hoZh1fra3/LhGLGxPyJCxcJ1cvA5e3r
L8PxdiLG0cs6VHMMVPOO64xs3R3XmH2k9ur2dTySz92rP9P2xh5ukYmf+7d+
BPE7vqKiprDTkWAHNh4oKxAdY8EoQqLBNHf/tTMkYXa0Z5JxzCThfuYAID4i
qA+JJZkjjBZEhT9KBRkJskSUllprL6p1pQ3h30ZUbqZzwZfs2QcUWhhD375X
oWgqBJqITRc14b3WpMqJbYRPGMaIjhbOpowuN95vbGAkeyNaO377+vXFr4fn
ry7ob/h/65c9XamNXn90yQ7cZMov6owbN9YWFdWeeOCqqGWUWYxOKQ0zxG+4
JdPHeua4fL7cNNuffeCEsd9SMN8PO9E3TLMclGVeElVplQF73PPUzGqyo/7V
dm7zz2A2l7LbF+P4/QVe3ku6kNoJSGBOKANDsaAwbRb+yX2G7O05afSWiE1W
y4O2ut40okYmwayZH9DkLxDd9wJrdzNcx+ucMCYNZmiI/iucZLnVHeetT5cO
y1aOZ5kZIkYcLutjdEp/+5PNESTpJVPjZ8/kd6MFTwqXc1dR0i6LNtn2tSxQ
Kyi8RNGeM+Fi9HemUZDPZwrqdh+4tPkdchp8BlQ4YTKcwB+wmlOFzW4BVi//
TNxGw+wXA9/27KLv2M0FtlT7SPYq48iL7n9fkzTXdoDDOSrxRQ+hwgIFLiPx
3Lg1golgSr+FuJBqMAvpwrXD+ojV3lGWMybzuySZclke28g6tRw0Tu7xTdCp
BPOKVQnROSgfVFQsohtWCEJ6glk7ggUrPb7WEW8WM90MyKyd9e4S9NXe0MvR
1o86CyrPeMA0cGfQ8EpAcy4vMBhXXVDzDmIbAjICQwkcKsFQ8I8pjb+2/2fh
l1rSOHNYLw3GhacyG0wvplj7EQ8ukP8Qw0/HqYMkwA8trhRX5Bug4pRRpQRd
W2qO22++UhIOObSt9T7nxvNgXZ50XbLBd3A5svjuInkPphBQpd4I/bdzoSC2
syCs7O79jFha8Z3v20f2NXwuVla4LvNFAz5o/pa7uVnmiWTV6J8HY7DLyu43
QXjR8x6NulZs9KWz5Brv5IITSi/G6TWXo+KEyQGWlUjPdlYOskarws0tds/X
CFbO3n1Nz/t0Vhlp7iydGXHhukDLtcGe1ozJFUsTCAUZw2C45OhKiXoyGSip
O+unwdi8XdSuAshGBSz4AkvpiezsYG8wZO4yBJvNO50rdrGuwRJuEc9v3lOj
4hPah2ss2BAEsh+tYiAVSaChSHPOy0qDIqmKu2WXwOkNdHIPWwECxGHZt8zb
Tu7UfCHGuHLKlm1HvQH403y9YVFDlnl6wz9FcWjjwx+B48E8x4qHgk7J6Oj8
rWk9gTYeecJHyYyhSnuf+RhO4nVOmEbiO5ezoWvrMcQNQhoR27RI80Jd44JH
ITEExLcg3mFAFVBeiMbQxCQHg1lanftqd1zPieOKTKa/tAzs5uvOs+31CiMj
xgi1LuC7QH3kiZiVxUxxDyv30roQDzeIWktNE0Yv4d0nGGh7CaXnEwLu9BH6
ZTaZETNveeHaiYPnaILsCRYu2/i9dZ7diHxIDzs7hB4Jp8izgw0KTkA5N3uk
+BKI0Fork4RTD9Z7hsff+0uc8lwe0blXH/4Yflq6Q8ajkDNuHGw0mBEWR+gQ
1HINEkYDA7OZ3Zlaisvjg18v9t4cHx/snR++Ob443DdqR+tKJo6nzV8MSEiB
9mLQ0NiwmjNfl+LQG5fTxUhfamrIgSp2JHBLTHBsXyiRpCxjRBp/z9Bx1GOD
OmUghhHtLIYkpd2YLWuhbjHapQ2bsXgMDzdnZd6E1SjqYsC4iXLEUUyoHn8m
Zn15sru/f3j8k/r3Pd1PYz6OOADTp8jyb0mRc3QGrve5k+HWhEP+GGhnM/gB
kkWFSEBYZ7Tlgrxqn2Fs1chjhyII+gVJRbQX9GAJR1uGIlFKbo11ZJrKehhL
6hZ+QcXkBtSwH8MwiAfEO9BcPrLAsEsKG0gC40LtXFmLguuAiTcZWSOmHF+L
l1A/uJ5lcVHX7986i6kZhsXodGzcvcm0S29AyjONG47JAjRquZp7VhW3TN1i
2ZrH+PNpFTbC1VXiZKmdnhlWAEZDNV9efnpwdnB+cXZ+erB75Lf1VKKKVwbg
bkitkxT/1UoacfLIqUujGwTrxouSkcfnkDMIJAnVoJkp+TQ2lVDc/CD+hYP2
N/aMsKa5BpBpOKis+Oz8zcnF2cFxeI9eWt8b4f4SOBJBqesdowBdxvBILHGJ
viYgU6kpDh4G3SSZHiHc0Teg/8QFaqn5xB2fNgnwIZ5vS00WU4C/K8Qis4sv
3eht6snl3unfTs7fNLmDu5BhHKgZ2mkdFSXQ+ZufD45b7p1KOGnwRoYM+SuI
SSN0b6Ys+0qEv2jqojIwuEEaGhTsCBjOiNN6vuSPYggcIcNWEslco9Iu40vN
yvr9IHj3u7INKJf9JqJ1SJwUcbUIT9qpK186AE7q5SEcCLY2h+U0Zmgu3NWd
ubeOGwqKYtvdxasHyoHTgsOxWm/r8qPhzI92//3Chqlr1282pVB5yD5b6BKH
4XV/3dHO7pUv6UQAGGkrtUVD6PMG9UnkD2UiqZyTTl/tc8BlXLx4/Wbv54N9
P4ljM3XLPqVwUHOBgl1H3oOVf/DCqetPpnshdNAWb0CzTcRIY3Zmr7/OJDl2
IW4PzzN/n3mf1eZc3jtpX0UBbylHDKRK7mdH6VczgdnQ9iYD4IPI6hi6s50s
nK0DH/RHIq5iAWjRK3Q3TeYy4zZzwOqC2hGUyZPhbUz1cT+0YLgvKvcWUwco
YUBHWTp5p1iZt6PE8U/uuzfRlnpfmdmeHpwfnh7MW+RhWG7S8IJOctJQuTVc
qNXqjQQlkxHAaQZWc/qayzjZPX91sfdq9/Xrg+OfDpqnBCcPWgaRgO6x1yzi
iZrPcHYelFkNyWVknp8E6Hgnb47PzBzORA67pCB6c/uU2xUNfzh7r9/YoYMr
hYC0gsSNy1rHGw/T7ZOKbxZRjmYV3OLGGmCvuKja96qWU6mSuOjiIwjJXCGw
M8nLDx8w14uR+NUAdT9F3H2e/qvd4/2zV7s/H1zsvzmun01NrXG8XjUZZQ3z
dCm83oqP2uJFctYnvhQOs8X8fMnfLGt/ipJgLVD56PewQc+YQZ0Dg0LP7B3D
Ns/aItq4eHJuS/rIyawcEWcLJCKfCX0HN/SjRxiUfs5j8jU43C7XQQ3Dw3D7
4yJDH3lbPmvva4+mMtpogoiLKkDiRKmiwX9fL7+hvLte+xPtvyRCDTNHH/I+
7czXQxd0SrG4RulDeApLTO3hgxK32D3eO3h9gXva5IOawdrHrgWZx5CWGzhF
ugh8vfSJyl+yrzjjme+a07OoENEbraUqAwfn52D5mS210LuycLg6ljslFcq8
duOorXaoZSdr6brN/fycZzB9UM7J1m26FPyyjrV7lVxrMOM2vuvpXYZrF4R3
mNPdlziTlgY5jtpbZq3bgT+T3FB+tRQ+hd0S2I3B3jv49k5DMOp2hCME3WWg
vTF4CtoRjJQybqEam95qDUz+0HYJwfLoNH96s/vr7t/8OR5Q663JHJmmmgfJ
tYa1StH+GXZDii2EI7VsRHD3IGRBK5Akmi+QgsaWoZNoqIcNz5Lq0eTD47TS
8PI5TUs3tu/s9apdOdh9fX72yx534fp+y2NoevWDHCnEPdp6JOIuyS30p9N4
zRs6gvZ3lBRhbcpdrxyIRR0KX3npEX/3ZxO8r2bDITYNEGBvpJ9C6AC+NGgv
vgmcPoLZDCWfNj8Eqn1FYDYymKAvf8WBJHAFmhFvcdvIxBekwCh5D9SZIK5p
Ujq4KjNA+9weOAJMav9uAsrVolnBVUqKyoykAKvBkxTd8Z3RRvOnVhHSKU8Q
dubtZCaY6xRrxUaCzqYQyxdThkKS79z7Y0/fKh+6hkKadB4daefePUNITuOU
hs9Jll9zo9bTl3vRwQB7iIAVr81aT9Cln3BjXmHuipnkRDbXMznxGsNoQ8KD
0TBpo+kHQ6tSN71BEQ8rjK8PZglfXF4iFW9sPFtZ6UZv2TfgZAyRJ7H2X3+K
Drv79O+wQw3jlsK/NgMgU/hgC/EBmmPiEOT2oGzvNy9fghYh3IxmuPyUny41
ZZzDKW8qUHBW/6k2sw/6J7vVIrMe5JNvEZ8qpYLwO+p0jYPuDga1sSgJsH1p
MNzyC3uy9ML2sthHZ2pwESGmmamj802gOCVjCKYwu04Rq7EbvUzf1x/WhjYV
902jKOc/ZjnqM8ys9DmOawnHwN4LdWT9UnoRGDBmSSGCsUfbY0MyGXw8o7aY
RY5Qx7T4WsiYlN5hpv0B+9RkcZr0SzMOn0BYqDEN4KnxpOEd1wRBgh1+4goD
nzqYm70lJu62LBdY+n44Hc47qFAAt2pyixZ6gplywm9x3iG7JPYn+YBjTdvE
uE6cIWq1Q9dz8zevasODb1lx2TG13MSS8C+UceW4z5ONjUgz6XCS0gND1EOb
aNfhzDX+B07mBM4MO5LrbM4lJpMqhKXkYnL7BqZxDuLHVdifTnpR3VB8FW8n
Jvotf9MeL33TpDlzrWhIBMkkv4VL9z5xcNzoXPJs2qleeGOZ2KnBJSe+aQOk
aWZxLEsHyq8ZVLd8wbWHhvP2Hu4bqqQIGirpV1liG06XhKvomk4w9wbi9UnZ
b7TPc7kq3C11BsMVqCt1R495qabyWOtvQh08xb1ziRt/2ezUYd23ONIgWnM4
gASIzs7qwbp5GQncE5SIMD+plPFHp4wZ+85cevj4lnfjL19gB0N4+zSsA9Dj
l/gR5TvyvmJeI5hmJhRszjRgd6yvEENblhgfLUWMHVUR8MPu2cnhcS9a44HT
pBrysL5B8dbGuh/VwKRy9am/+hOCjLf+Xf7F4sG31gMhlLjomt4DOodF6Zs6
JZPWsuiFm2Y11IiFzS5yKxLnwCpvEH5teWP0ezKN7SUwzNHEC0pxd3i/CTq1
+ti5mTpC0rvq86TD3PzBy1B04Qwm6BW/jQssHS0lrsFTTSeJ7DKJTCVRvQJm
ZoSum2qjvpuaOoX65DPMKkFnPLbiLXN0mJb0xdajJxtWVfDVpT7Jyp87J1rV
vPX4+BGSHJv0Sv55zULjS4rydOA4+5l4o/HXRnTbj8dpUeQF99CaVvUeiL0a
gXFkF8E5Y6BafxE5qOIqH6t8+Xu3vby6xRedvdXGTU2U5TheikWYPnYyQLDh
fGIcRBvmZFmBkQORHDTqEjEv30wEKFsztCW+mbzzluSg6JZ9ILiOibngsAd7
x+blTpagjpGW+k/bD1p8AI5PNLUs4ctNVfjkzfFP6u5dcKc3iUPJ1hJFcRGx
klfLw3zRntrnSGXCI8O/zH2EXhVs3v7bk9eHe7vnB+TkkekammupEo7WSBBT
TKxeVEw/YH1H8zCwnbVSyrrKJ6/e5BPtD1ZhTReMADcAZue3dkC5HkQgpBOq
IuS0hppO3I8noqSTfh9gWFMdWFCDbhP+6gzOXkRnjT7ubfa2lr9dW7AOzFan
cyqXf24Tb+WBeumuZynPC/lSIwrM+ezeVe4ofBA8iPlu0Rq19QbSXPeHDSdC
GhXJ+CItUVhoFFrL8gMli8KIevEqdd8LlAG9vkyc/PM0jcahf6ujw90TpsHD
N8cRhQD5Nx1ObZ3LeOX4+sqiTyURNRBbxkCia+u7oumBuGVpsZcDS6csSNpb
eyMaEjvUM9fayrkoij9G9WAywPa8d+sN+wxINhbmNblhkMXliWXjAa6ALH7v
1oCmA5s4ZgVqjtlFu57n6F+WqEhzI4LWNKWXh9HqITUlpVuPs1r96ywFBg2/
UmW7DV+9rhkp72hFTZ/z49ZOZu0/P02mGbK3vTcn50D/19xHrosdJ8taZwHf
3UmclPI21/iWMtHCjkFhRRqN12+D5guaqvdW/i+Mo8KAeZwBAA==

-->

</rfc>

