Skip to main content

HTTP Alternative Services, Plan B
draft-thomson-httpbis-alt-svcb-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Martin Thomson , Mike Bishop , Lucas Pardue , Tommy Jensen
Last updated 2022-10-24
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-thomson-httpbis-alt-svcb-00
HTTP                                                          M. Thomson
Internet-Draft                                                   Mozilla
Obsoletes: 7838 (if approved)                                  M. Bishop
Intended status: Standards Track                     Akamai Technologies
Expires: 27 April 2023                                         L. Pardue
                                                              Cloudflare
                                                               T. Jensen
                                                               Microsoft
                                                         24 October 2022

                   HTTP Alternative Services, Plan B
                   draft-thomson-httpbis-alt-svcb-00

Abstract

   HTTP alternative services

   This document deprecates RFC 7838.

About This Document

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

   The latest revision of this draft can be found at
   https://martinthomson.github.io/alt-svcb/draft-thomson-httpbis-alt-
   svcb.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-thomson-httpbis-alt-svcb/.

   Discussion of this document takes place on the HTTP Working Group
   mailing list (mailto:ietf-http-wg@w3.org), which is archived at
   https://lists.w3.org/Archives/Public/ietf-http-wg/.

   Source for this draft and an issue tracker can be found at
   https://github.com/martinthomson/alt-svcb.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

Thomson, et al.           Expires 27 April 2023                 [Page 1]
Internet-Draft                  Alt-SvcB                    October 2022

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 27 April 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Caching in Alternative Services . . . . . . . . . . . . .   3
     1.2.  A New Alternative . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Conventions and Definitions . . . . . . . . . . . . . . .   4
   2.  Using Alternative Services  . . . . . . . . . . . . . . . . .   5
     2.1.  Retention of Alternatives . . . . . . . . . . . . . . . .   6
     2.2.  Reusing Alternatives  . . . . . . . . . . . . . . . . . .   7
       2.2.1.  Example of Reuse  . . . . . . . . . . . . . . . . . .   7
       2.2.2.  Exclusive Alternative Services  . . . . . . . . . . .   8
     2.3.  Port Numbers  . . . . . . . . . . . . . . . . . . . . . .   9
     2.4.  Interaction with GOAWAY . . . . . . . . . . . . . . . . .   9
     2.5.  Proxies . . . . . . . . . . . . . . . . . . . . . . . . .   9
     2.6.  Fallback to Alt-Svc . . . . . . . . . . . . . . . . . . .  10
     2.7.  No Authority  . . . . . . . . . . . . . . . . . . . . . .  10
   3.  Protocol Elements . . . . . . . . . . . . . . . . . . . . . .  11
     3.1.  Alt-SvcB Field  . . . . . . . . . . . . . . . . . . . . .  11
     3.2.  ALTSVCB Frame . . . . . . . . . . . . . . . . . . . . . .  12
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   5.  Internationalization Considerations . . . . . . . . . . . . .  13
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  15

Thomson, et al.           Expires 27 April 2023                 [Page 2]
Internet-Draft                  Alt-SvcB                    October 2022

   Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   HTTP alternative services provide an HTTP server with a means to
   direct requests from clients to an alternative server instance.
   Clients that learn about an alternative service can establish a
   connection to the identified instance, which - if successfully
   established and authenticated - can be used for future requests.
   This design allows for nearly seamless service continuity in some
   conditions.

   The use cases that might motivate a server to direct future requests
   to a different server instance vary.

   *  Some deployments might seek to direct a client to a server
      instance that is better able to serve requests for that client.
      This might occur if DNS resolution of the server name produces the
      address of a server instance that is further from the client.

   *  Servers that might seek to shed load, perhaps in anticipation of
      an imminent shutdown or maintenance action, might use an
      alternative service declaration to reduce either server load or
      the number of clients that might be affected.

   *  Many deployments of HTTP/3 [HTTP/3] use the protocol identifiers
      in an alternative service declaration to make clients aware of
      support for the newer protocol.

   These different use cases can sometimes create awkward trade-offs for
   deployments of alternative services.

1.1.  Caching in Alternative Services

   With RFC 7838 [ALT-SVC], setting the "ma" (or max-age) parameter for
   an alternative can be challenging for a server deployment.  Setting
   too a large max-age can mean that clients use an alternative for
   longer than they should.  Conversely, a short cache period for an
   advertisement for HTTP/3 can mean that earlier versions might be used
   more often than is optimal.

   Alternative services can interact poorly with service configuration
   information that is published in the DNS.  With the introduction of
   HTTPS records [SVCB], the availability of HTTP/3 can be advertised in
   the DNS, creating two independent sources of this information, with
   different approaches to caching.

Thomson, et al.           Expires 27 April 2023                 [Page 3]
Internet-Draft                  Alt-SvcB                    October 2022

   Alternative services can also be highly dependent on networking
   conditions.  RFC 7838 attempted to manage this by having clients be
   responsible for invalidating alternatives when changes in their
   network are detected, unless the alternative is explicitly marked as
   "persistent".  In practice, detecting the necessary changes is
   difficult for many clients, so this requirement is not consistently
   implemented.

   The alternative services mechanisms defined in RFC 7838 can produce
   suboptimal or even detrimental outcomes in some deployments.
   Consequently, this document obsoletes RFC 7838.

1.2.  A New Alternative

   This document describes a different approach to advertising
   alternative services.  This approach uses the DNS as the singular
   source of information about service reachability.  An alternative
   service advertisement only acts as a prompt for clients to seek
   updated information from the DNS.

   To use this new design, a server advertises an alternative name using
   the "Alt-SvcB" field.

   200 OK HTTP/1.1
   date: Mon, 24 Oct 2022 02:58:31 GMT
   alt-svcb: "instance31.example.com"
   content-length: 0

   Clients can then consult the DNS, making HTTPS queries [SVCB]
   starting with this name.  The alternative name is used in place of
   the name of the authority and using HTTPS records is mandatory, but
   the process otherwise follows normal HTTPS record resolution and
   connection procedures.  Section 2 defines how this name is used in
   detail.

   Future connections for requests to resources on the same server use
   HTTPS record resolution to the name of the authority, but are
   reprioritized if a successful connection was previously made to an
   alternative service.  Section 2.2 defines how this process works in
   more detail.

1.3.  Conventions and Definitions

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Thomson, et al.           Expires 27 April 2023                 [Page 4]
Internet-Draft                  Alt-SvcB                    October 2022

2.  Using Alternative Services

   When a client learns about a new potential alternative from a server,
   they SHOULD attempt to use that alternative for future requests to
   that server.  The client attempts to make a request for a resource on
   the same server using the alternative as follows:

   1.  The client makes a DNS query for HTTPS records for the
       alternative name, following the procedures in Section 3 of
       [SVCB].  Clients make this query as a "SVCB-reliant" SVCB client,
       treating a failure to obtain HTTPS records as a failed
       alternative.  If this process fails to produce service parameters
       or IP addresses, abort this process.  [[ISSUE: Maybe we can still
       be SVCB-optional here, but that places constraints on the choice
       of name.]]

   2.  The client establishes a connection using the service parameters
       and addresses learned from the DNS query.  Important here is that
       the client uses a TLS server name indication [SNI] of the server
       name from the URL, not the alternative name.  This allows the
       server to produce a certificate for that name, which the client
       can validate as applying to the URL it is resolving.  If a
       connection cannot be established, abort this process.

   3.  The client validates that the server is authoritative for the
       resource.  If the server is not authoritative, abort this
       process.

   4.  The client makes a query for the resource.  If the server does
       not respond, responds with a 421 (Misdirected Request) (see
       Section 15.5.20 of [HTTP]), or a 5xx status code (see
       Section 15.6 of [HTTP]), abort this process.

   5.  Once a response is received, the connection to the alternative is
       complete.  Any other connections can be closed and future
       requests directed to the alternative.  The client SHOULD remember
       the alternative name and the service name (the TargetName from
       the HTTPS ServiceMode record that was used) that were used; see
       Section 2.1.

   A client MUST NOT remember a service name for an alternative service
   until a request has been successfully completed with a 2xx or 3xx
   status code.  A client MAY send additional requests using the newly
   established connection to the alternative service after it verifies
   that the server is authoritative.  The alternative service is
   therefore active once the connection is established, but it will not
   be reused (Section 2.2) for future connections until a request
   completes successfully.

Thomson, et al.           Expires 27 April 2023                 [Page 5]
Internet-Draft                  Alt-SvcB                    October 2022

   A client MAY continue sending other requests over any existing
   connection to the server until this process completes in order to
   minimize latency for those requests.  A client MAY - when presented
   with an alternative name - proactively make a request for an
   arbitrary resource on the server, rather than waiting for the next
   time a request is needed.  This might allow the connection to be
   available for future requests with less delay.

2.1.  Retention of Alternatives

   Clients SHOULD remember the successful use of an alternative service.
   Two pieces of information are retained:

   *  the alternative name, which is the name provided by the server in
      the Alt-SvcB field or ALTSVCB frame, and

   *  the service name, which is the TargetName from the ServiceMode
      HTTPS record that was used to successfully connect to the server.

   These two names are saved for the server against the origin of the
   server [ORIGIN].  Clients MUST NOT reuse saved information for a
   server with a different hostname, port, or scheme.

   The name given in an Alt-SvcB field or ALTSVCB frame is retained only
   so that the client can avoid initiating a connection to an
   alternative if it has already made an attempt.  Any time that a
   server provides a different name in an Alt-SvcB field or ALTSVCB
   frame, any existing information MUST be discarded.  A client MAY then
   initiate a DNS query and connection attempt to the identified
   alternative.  A client can subsequently ignore repeated fields or
   frames.

   A server might provide an Alt-SvcB field in all responses it sends.
   Only acting on a value once ensures that this repetition has no
   effect on clients.  Though a server might repeat the field, clients
   MUST NOT consider an absent field as indicative of a retraction of a
   previous advertisement.  An alternative name is only removed when
   explicitly replaced or when a remembered service name does not appear
   in the set of HTTPS query responses.

   On the first attempt to use an alternative, a failed alternative
   SHOULD be remembered using an alternative name and a null or absent
   service name.  This avoids making repeated attempts to use an
   alternative service that is not available if the server repeats the
   information in Alt-SvcB fields or ALTSVCB frames.  A client MAY
   periodically attempt to retry a failed alternative if the information
   is repeated.

Thomson, et al.           Expires 27 April 2023                 [Page 6]
Internet-Draft                  Alt-SvcB                    October 2022

   A server can explicitly request that a client remove any remembered
   service name by providing an alternative name of "invalid".  The
   "invalid" domain name corresponds to a DNS name that will never
   successfully resolve (see Section 6.4 of [SUDN]), which guarantees
   that an attempt to use this name cannot succeed.  Clients MAY
   recognize the name "invalid" as special and avoid any attempt to use
   this to discover an alternative service.

2.2.  Reusing Alternatives

   A client remembers the service name, or the TargetName from the
   ServiceMode HTTPS record that it successfully used to establish a
   connection to an alternative service.  In subsequent connections to
   the same server, it makes HTTP queries for the server name.  If this
   query returns a ServiceMode resource record (RR) that includes a
   TargetName that is identical to the remembered service name, the
   client SHOULD choose that over any alternatives, including those RRs
   that are marked "alt-only"; see Section 2.2.2.

   A client does not make a query for the remembered alternative name.
   They make a query for the name of the server, using the QNAME derived
   from the URI of the target resource.

   The RR that matches the remembered service name is selected,
   overriding any SvcPriority that might otherwise result in another
   ServiceMode record being chosen.

   If a query for HTTPS records does not produce a ServiceMode record
   with a matching TargetName, any remembered information MUST be
   removed for that origin.

   When reusing stored information, if a connection is unsuccessful for
   any reason (see Section 2), remembered information for that origin
   MUST be removed.  Clients clear retained alternative service
   information on reuse to prevent stale information from affecting all
   future connection attempts.  After removing remembered information, a
   client MAY make another attempt to connect using any other
   ServiceMode records that the DNS query produced.

2.2.1.  Example of Reuse

   A client that is fetching "https://example.com/" might originally
   perform a DNS query for "example.com" and receive in response:

   example.com.  7200 IN HTTPS 1 . port=443
   alt1.example. 7200 IN HTTPS 10 . port=8443
   alt2.example. 7200 IN HTTPS 10 . port=8443
   alt3.example. 7200 IN HTTPS 10 . port=8443

Thomson, et al.           Expires 27 April 2023                 [Page 7]
Internet-Draft                  Alt-SvcB                    October 2022

   Under normal conditions, the SvcPriority of the "alt?.example."  RRs
   would indicate that it is not preferred, so the "example.com" record
   would be used.

   If the client received an alternative service advertisement from this
   server for "alt.example.net" it would then make a DNS query to that
   name.  This might return a different set of records, as follows:

   alt2.example. 7200 IN HTTPS 1 . port=8887
   alt3.example. 7200 IN HTTPS 1 . port=8887

   If the client selects "alt2.example." and successfully connects to
   that host, it remembers both the name given as an alternative name
   ("alt.example.net") and a service name (the TargetName from the
   ServiceMode HTTPS record, "alt2.example.").

   In subsequent connections to "example.com", the client again queries
   the "example.com" name.  Importantly, this is not any other name it
   might have learned.  The resulting response - after following
   indirections through AliasMode, CNAME, or similar mechanisms -
   produces the same records as previously:

   example.com.  7200 IN HTTPS 1 . port=443
   alt1.example. 7200 IN HTTPS 10 . port=8443
   alt2.example. 7200 IN HTTPS 10 . port=8443
   alt3.example. 7200 IN HTTPS 10 . port=8443

   The ServiceMode HTTPS record for "alt2.example." is used, even though
   this is a lower priority than other records.  It is also used despite
   not using the same port number as previously.

2.2.2.  Exclusive Alternative Services

   ServiceMode HTTPS records can be marked as only being available for
   use as an alternative.  This allows servers to use alternative
   services for specific server instances, without having clients
   connect to them without being first invited to do so.

   This is achieved with a SvcParam with a key of "alt-only" (codepoint
   TBD).  The value of this SvcParamKey MUST be empty.  HTTPS
   ServiceMode records with this SvcParamKey MUST NOT be used unless the
   client is actively seeking an alternative, either as a result of
   actively looking up an alternative name or because the alternative
   has been remembered.

   To prevent clients that do not support this specification from using
   these services, the "alt-only" SvcParamKey MUST be listed in the
   "mandatory" SvcParam.

Thomson, et al.           Expires 27 April 2023                 [Page 8]
Internet-Draft                  Alt-SvcB                    October 2022

   In the following example, though "alt1.example" is listed at a higher
   priority than "example.com", clients will not use this service unless
   an alternative was provided by the server:

   alt1.example. 7200 IN HTTPS 1 . port=443,alt-only,mandatory=alt-only
   example.com.  7200 IN HTTPS 2 . port=443

   [[ISSUE: Do we need this flag in addition to the priority override?
   Could one of the two be sufficient?]]

2.3.  Port Numbers

   The name that is provided in the Alt-SvcB field or ALTSVCB frame can
   be any valid DNS QNAME.  This includes those with underscored labels
   [ATTRLEAF], including those that might be used to query for HTTPS
   records to a non-default port.

   200 OK HTTP/1.1
   date: Mon, 24 Oct 2022 02:58:31 GMT
   alt-svcb: "_8443._https.example.com"
   content-length: 0

   This might be used to direct clients to connect to alternative ports.
   Note that the HTTPS records might direct clients to an entirely
   different port number than the name implies.  Clients MUST NOT infer
   a port number from the provided name, instead treating this name no
   differently than any other.

2.4.  Interaction with GOAWAY

   Servers that advertise alternative services cannot expect clients to
   switch to the advertised alternative.  Use of the alternative is
   entirely at the discretion of clients.  If the client is unsuccessful
   in connecting to an alternative or does not attempt a connection,
   they could continue to use the existing connection for new requests.

   A server that seeks to actively encourage clients to disconnect and
   seek service elsewhere needs to use graceful shutdown procedures of
   the HTTP version that is in use.  HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3]
   each provide a GOAWAY frame that can be used to initiate the graceful
   shutdown of a connection.  Alternative services is not a substitute
   for these mechanisms.

2.5.  Proxies

   The procedures in this document apply to clients that connect to
   gateways or reverse proxies.  However, clients that connect via a
   proxy, using HTTP CONNECT or similar methods, have a choice.

Thomson, et al.           Expires 27 April 2023                 [Page 9]
Internet-Draft                  Alt-SvcB                    October 2022

   Clients that provide a proxy with the name of a service leave name
   resolution to the proxy.  Such a client MUST ignore any alternative
   service advertisement it receives and MAY fallback to using legacy
   alternative services; see Section 2.6.

   Clients that make HTTPS queries for any connection attempt via a
   proxy can use alternative services.  Such a client MUST provide the
   proxy with the IP address of the server it wishes to contact, rather
   than providing a name.

2.6.  Fallback to Alt-Svc

   A client that successfully makes use of HTTPS records in resolving
   the name of an HTTP server MUST ignore any Alt-Svc fields or ALTSVC
   frames [ALT-SVC] that the server provides.  This document deprecates
   the mechanisms defined in RFC 7838 [ALT-SVC].

   Servers might provide Alt-Svc fields or ALTSVC frames [ALT-SVC] in
   order to support clients that cannot use HTTPS records.

2.7.  No Authority

   This design does not assume that information that a client learns
   about alternatives is authoritative in any way, either by virtue of
   being provided by an authoritative server.  Instead, once a server is
   determined to be authorative (see Section 4.3 of [HTTP]), that server
   is treated as the authority on all aspects of service configuration.
   For protocol choice, [ALPN] and maybe [SNIP] extensions in the TLS
   handshake [TLS] determine what is used.

   In contrast RFC 7838, sending alternative services over an HTTP
   connection ensures that the information is authoritative.  Clients
   therefore might have been less concerned about attacks that
   compromise the integrity of alternative services when using RFC 7838.

   Though integrity protection might appear to be valuable, it produced
   conflicts.  For instance, information about the protocol is
   ostensibly authentic when provided in Alt-Svc fields or ALTSVC
   frames.  However, protocol support is also authenticated when
   establishing a connection.  This creates a potential conflict between
   two equally authoritative sources of the same information.

   Conflicts also arise when alternative service information is retained
   as any retained state might disagree with what is currently deployed.
   This design avoids this contention by having the entire service
   resolution process occur almost entirely to the DNS.

Thomson, et al.           Expires 27 April 2023                [Page 10]
Internet-Draft                  Alt-SvcB                    October 2022

   An alternative service advertisement provides only a minimal nudge to
   perform a DNS query at the time it is made.  On reconnection,
   remembered state only affects prioritization of active DNS records.
   Invalid configurations do not persist.

3.  Protocol Elements

   Multiple ways of encoding an alternative service name is defined.
   The Alt-SvcB field in Section 3.1 allows servers to indicate a
   preferred service in responses.  The ALTSVCB frames in Section 3.2
   allows a server to provide alternative names outside of the context
   of a query.

   These approaches have different properties.  Alt-SvcB fields are
   forwarded by intermediaries and so might reach clients through a
   gateway or reverse proxy.  Clients that use a proxy without using
   CONNECT or similar tunnels, might also receive an alternative name
   using a field.  In comparison, ALTSVCB frames each only apply to a
   single origin within the scope of a single connection.

3.1.  Alt-SvcB Field

   The "Alt-SvcB" response field is a List of String values (see
   Sections 3.1 and 3.3.3 of [STRUCTURED-FIELDS]).  This response field
   MAY appear in a header or trailer section, though servers need to be
   aware that some clients might not process field values.

   Each field value includes an alternative name.  Each alternative name
   is encoded as an ASCII string, or a series of DNS A-labels, each
   separated by a single period character (".", U+2E).  Each value MAY
   end with a period, though - for the purposes of the process in
   Section 2 - the string is treated as an absolute DNS QNAME whether or
   not a trailing period is present.

   The applicable origin [ORIGIN] is derived from the origin of the
   Target Resource (see Section 7.1 of [HTTP]).

   If multiple Alt-SvcB fields or field values are present in a
   response, the client MAY use any subset of the provided alternative
   names, including none, one, or all of the provided names.

   Servers SHOULD NOT provide more than one name.  The DNS provides
   ample opportunity to present clients with options, including the use
   of priority to help manage selection.  A list is tolerated only to
   allow for the possibility that multiple field lines might be added to
   responses without proper coordination.

Thomson, et al.           Expires 27 April 2023                [Page 11]
Internet-Draft                  Alt-SvcB                    October 2022

   Clients MUST ignore unknown parameters that are provided with
   alternative names.  This document does not define any parameters as
   the DNS is expected to provide supplementary information about
   services; a revision of this document would be required to enable the
   use of parameters.

3.2.  ALTSVCB Frame

   An ALTSVCB frame is defined for both HTTP/2 and HTTP/3.  The frame
   provides an alternative name for an identified origin [ORIGIN].

   In both protocols, the ALTSVCB frame uses the identifier TBD.  The
   format for both protocols is the same; this is shown in Figure 1
   using the notation from Section 3 of [QUIC].

   ALTSVCB Frame {
     Origin Length (i),
     Origin (..),
     Alternative Name (..),
   }

                       Figure 1: ALTSVCB Frame Format

   The fields in the ALTSVCB frame are defined as follows:

   Origin Length:  An integer, encoded as a QUIC variable-length integer
      (see Section 16 of [QUIC]) indicating the length of the Origin
      field, in bytes.

   Origin:  The ASCII serialization of the affected origin; see
      Section 6.2 of [ORIGIN].

   Alternative Name:  The remainder of the frame contains a single
      alternative name, encoded as an ASCII string; see the definition
      in Section 3.1 for more details on the encoding.

   If a server sends multiple ALTSVCB frames for the same origin,
   clients MUST ignore any frames other than the most recent.

4.  Security Considerations

   TODO Lots of work to do here.  Review RFC 7838 for relevant
   information to copy over.

Thomson, et al.           Expires 27 April 2023                [Page 12]
Internet-Draft                  Alt-SvcB                    October 2022

5.  Internationalization Considerations

   An internationalized domain name that appears in either an Alt-SvcB
   field (Section 3.1) or an ALTSVCB frame (Section 3.2) MUST be
   expressed using A-labels; see Section 2.3.2.1 of [RFC5890].

6.  IANA Considerations

   TODO register:

   *  Field

   *  H2 Frame

   *  H3 Frame

   *  alt-only SvcParam

7.  References

7.1.  Normative References

   [ALPN]     Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.

   [ALT-SVC]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.

   [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [ORIGIN]   Barth, A., "The Web Origin Concept", RFC 6454,
              DOI 10.17487/RFC6454, December 2011,
              <https://www.rfc-editor.org/rfc/rfc6454>.

   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

Thomson, et al.           Expires 27 April 2023                [Page 13]
Internet-Draft                  Alt-SvcB                    October 2022

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/rfc/rfc5890>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [SNI]      Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,
              <https://www.rfc-editor.org/rfc/rfc6066>.

   [STRUCTURED-FIELDS]
              Nottingham, M. and P-H. Kamp, "Structured Field Values for
              HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
              <https://www.rfc-editor.org/rfc/rfc8941>.

   [SVCB]     Schwartz, B. M., Bishop, M., and E. Nygren, "Service
              binding and parameter specification via the DNS (DNS SVCB
              and HTTPS RRs)", Work in Progress, Internet-Draft, draft-
              ietf-dnsop-svcb-https-11, 11 October 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
              svcb-https-11>.

   [TLS]      Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

7.2.  Informative References

   [ATTRLEAF] Crocker, D., "Scoped Interpretation of DNS Resource
              Records through "Underscored" Naming of Attribute Leaves",
              BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
              <https://www.rfc-editor.org/rfc/rfc8552>.

   [HTTP/2]   Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
              DOI 10.17487/RFC9113, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9113>.

   [HTTP/3]   Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

Thomson, et al.           Expires 27 April 2023                [Page 14]
Internet-Draft                  Alt-SvcB                    October 2022

   [SNIP]     Thomson, M., "Secure Negotiation of Incompatible Protocols
              in TLS", Work in Progress, Internet-Draft, draft-ietf-tls-
              snip-02, 30 June 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              snip-02>.

   [SUDN]     Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <https://www.rfc-editor.org/rfc/rfc6761>.

Contributors

   RFC 7838 [ALT-SVC] was authored by Patrick McManus, Julian Reschke,
   and Mark Nottingham.  This draft contains none of that work, but many
   of those same basic ideas.

Acknowledgments

   This work is input to discussions with a design team on HTTP
   alternative services, formed after realizing that a simple revision
   to RFC 7838.  Though it is informed by discussions thus far, it is
   NOT the product of that group.  Thanks are due to those who have
   participated in those discussions, who the author is to cowardly to
   list due to the risk that someone is missed.

Index

   A

      A

         Alt-SvcB  Section 1.2, Paragraph 2; Section 2.1, Paragraph 2,
            Item 1; Section 2.1, Paragraph 4; Section 2.1, Paragraph 4;
            Section 2.1, Paragraph 5; Section 2.1, Paragraph 6;
            Section 2.3, Paragraph 1; Section 3, Paragraph 1; Section 3,
            Paragraph 2; Section 3.1, Paragraph 1; Section 3.1,
            Paragraph 4; Section 5, Paragraph 1
         ALTSVCB  Section 2.1, Paragraph 2, Item 1; Section 2.1,
            Paragraph 4; Section 2.1, Paragraph 4; Section 2.1,
            Paragraph 6; Section 2.3, Paragraph 1; Section 3, Paragraph
            1; Section 3, Paragraph 2; Section 3.2, Paragraph 1;
            Section 3.2, Paragraph 2; Section 3.2, Paragraph 4;
            Section 3.2, Paragraph 6; Section 5, Paragraph 1

Authors' Addresses

   Martin Thomson
   Mozilla

Thomson, et al.           Expires 27 April 2023                [Page 15]
Internet-Draft                  Alt-SvcB                    October 2022

   Email: mt@lowentropy.net

   Mike Bishop
   Akamai Technologies
   Email: mbishop@evequefou.be

   Lucas Pardue
   Cloudflare
   Email: lucaspardue.24.7@gmail.com

   Tommy Jensen
   Microsoft
   Email: tojens@microsoft.com

Thomson, et al.           Expires 27 April 2023                [Page 16]