2. 代替サービスの概念
本仕様は、HTTP の新しい概念である「代替サービス（Alternative Service）」を定義します。オリジン [RFC6454] が異なるプロトコル/ホスト/ポートの組み合わせを通じてアクセス可能なリソースを持っている場合、代替サービスが利用可能であると言われます。
代替サービスを使用して、ネットワーク上の別の場所にあるオリジンサーバー上のリソースと対話できます。場合によっては、異なるプロトコル構成を使用します。代替サービスは、[RFC7230] セクション 9.1 の意味において、オリジンのリソースに対して権限がある（authoritative）と見なされます。
例えば、オリジン：
("http", "www.example.com", "80")
が、そのリソースが代替サービスでもアクセス可能であると宣言する場合があります：
("h2", "new.example.com", "81")
その性質上、代替サービスは明示的にオリジン単位（granularity of an origin）です。オリジン内のリソースに選択的に適用することはできません。
代替サービスは、特定のリソースのオリジンを置き換えたり変更したりしません。一般に、アクセス・メカニズムの「上」にあるソフトウェアには見えません。代替サービスは本質的に代替ルーティング情報であり、DNS CNAME または SRV レコードが名前解決レベルでルーティング情報を定義するのと同じ方法で、オリジンに到達するために使用できます。各オリジンはこれらのルートのセットにマップされます。デフォルトルートはオリジン自体から派生し、他のルートは代替サービス情報に基づいて導入されます。
さらに、代替サービス・タプルの最初のメンバーは、オリジンの「スキーム」コンポーネントとは異なることに注意することが重要です。それはより具体的であり、使用されているプロトコルのメジャーバージョンだけでなく、そのプロトコルの通信オプションも識別する可能性があります。
これは、代替サービスを使用するクライアントがリソースを取得するために使用しているホスト、ポート、およびプロトコルを変更できることを意味しますが、これらの変更は HTTP を使用しているアプリケーションに伝播されてはなりません（MUST NOT）。その観点からは、アクセスされている URI とそこから派生したすべての情報（スキーム、ホスト、およびポート）は以前と同じです。
重要なことに、これにはセキュリティコンテキストが含まれます。特に、認証に TLS [RFC5246] が使用される場合、代替サービスは代替のホスト名ではなく、オリジンのホスト名の証明書を提示する必要があります。同様に、Host ヘッダーフィールド（[RFC7230]、セクション 5.4）は、代替サービスではなく、依然としてオリジンから派生します（CNAME が使用されている場合と同様）。
ただし、変更はデバッグツールやコンソールなどで表示される場合があります（MAY）。
正式には、代替サービスは以下の組み合わせによって識別されます：
- [RFC7301] に従った Application Layer Protocol Negotiation (ALPN) プロトコル名
- [RFC3986] セクション 3.2.2 に従ったホスト
- [RFC3986] セクション 3.2.3 に従ったポート
ALPN プロトコル名は、代替サービスによって使用されるアプリケーションプロトコルまたはプロトコルスイートを識別するために使用されます。本仕様の目的のために、ALPN プロトコル名は、定義で別途指定されていない限り、識別するプロトコルスイートに暗黙的に TLS を含むことに注意してください。特に、[RFC7301] のセクション 6 によって登録された ALPN 名 "http/1.1" は、TLS 上の HTTP/1.1 を識別します。
さらに、各代替サービスには、秒単位で表される新鮮度寿命（freshness lifetime）が必要です（セクション 2.2 を参照）。
クライアントがオリジンに関連付けられた代替サービスを発見する方法はたくさんあります。本ドキュメントでは、そのような 2 つのメカニズム、「Alt-Svc」HTTP ヘッダーフィールド（セクション 3）と「ALTSVC」HTTP/2 フレームタイプ（セクション 4）について説明します。
このセクションの残りの部分では、発見方法に関係なく、代替サービスに共通する要件について説明します。
2.1. ホスト認証
クライアントは、代替サービスがオリジン全体の制御下にあり、有効であるという合理的な保証（reasonable assurances）を持たなければなりません（MUST）。これにより、セクション 9.2 で説明されている攻撃が軽減されます。
本ドキュメントの目的のために、「合理的な保証」は、[RFC2818] で定義された証明書チェックを備えた TLS ベースのプロトコルを使用することで確立できます。クライアントは、合理的な保証を確立するための追加の基準を課すことができます（MAY）。
例えば、オリジンのホストが "www.example.com" であり、代替が "h2" プロトコルを使用して "other.example.com" で提供され、提示された証明書が "www.example.com" に対して有効である場合、クライアントは代替を使用できます。しかし、どちらかが "h2c" プロトコルで提供されている場合、クライアントはそれを使用できません。なぜなら、そのプロトコルには（本仕様の発行時点で）オリジンと代替の関係を確立するメカニズムがないためです。
2.2. 代替サービスのキャッシュ
代替サービスを発見するためのメカニズムは、それらに新鮮度寿命（freshness lifetime）も関連付けます。例えば、Alt-Svc ヘッダーフィールドは "ma" パラメータを使用します。
クライアントは、新鮮であると見なされるときはいつでも、オリジンの代わりに代替サービスを使用することを選択できます。具体的な推奨事項については、セクション 2.4 を参照してください。
代替サービスへの既存の接続を持つクライアントは、その新鮮度寿命が終了したときにその使用を停止する必要はありません。キャッシュメカニズムは、代替サービスを新しい接続の確立に使用できる期間を制限することを目的としており、既存の接続の使用を制限することを目的としていません。
代替サービスは、当該オリジンに対して完全に権限があり、キャッシュされた代替サービスエントリのクリアまたは更新、新鮮度寿命の延長、およびオリジンサーバーが持つその他の権限を含みます。
代替サービスを使用してクライアントを最も最適なサーバーに送信する場合、ネットワーク構成の変更により、キャッシュされた値が最適でなくなる可能性があります。したがって、クライアントは、ネットワーク状態に関する情報が利用可能な場合にそのような変更を検出したとき、値が "1" の "persist" フラグがないすべての代替サービスをキャッシュから削除すべきです（SHOULD）。
2.3. Server Name Indication の要求
クライアントが TLS Server Name Indication (SNI) をサポートしていない限り、クライアントは TLS ベースの代替サービスを使用してはなりません（MUST NOT）。これは、代替サービスホスト上の IP アドレスの節約をサポートします。
クライアントによって TLS で提供される SNI 情報は、代替の情報ではなく、オリジンの情報であることに注意してください（Host HTTP ヘッダーフィールド値と同様）。
2.4. 代替サービスの使用
その性質上、代替サービスはオプション（OPTIONAL）です。クライアントはそれらを使用する必要はありません。ただし、ロードバランシングなどの目的を支援するため、サーバーによって代替サービスが使用される場合にクライアントが予測可能な方法で動作することは有益です。
したがって、本仕様をサポートするクライアントが代替サービスを認識し、代替サービス情報が新鮮であり（セクション 2.2）、代替サービスプロトコルのセキュリティプロパティが既存の接続と比較して望ましい場合、クライアントは利用可能になり次第、関連するオリジンへのすべてのリクエストにその代替サービスを使用すべきです（SHOULD）。実行可能な代替サービスは、あらゆる点でオリジンとして扱われます。これには、代替サービスを通知する機能が含まれます。
クライアントが複数の代替サービスを認識した場合、セキュリティプロパティを念頭に置いて、独自の基準に従って最も適切なものを選択します。例えば、オリジンは、複数バージョンの HTTP のサポートをクライアントに通知するために、複数の代替サービスを通知する場合があります。
特定のリクエストに対してプロキシを使用するように構成されたクライアントは、このリクエストのために代替サービスに直接接続すべきではなく（SHOULD NOT）、そのプロキシを介してルーティングすべきです。
クライアントがリクエストに代替サービスを使用する場合、Alt-Used ヘッダーフィールド（セクション 5）を使用してサーバーにこれを示すことができます。
クライアントは、既存の接続上のリクエストをブロックする必要はありません。代替接続が確立されるまで使用できます。ただし、既存の接続のセキュリティプロパティが弱い場合（例えば、クリアテキスト HTTP/1.1）、情報漏洩を避けるために、新しい接続が完全に利用可能になるまでブロックすることが理にかなっている場合があります。
さらに、代替サービスへの接続が失敗したり応答しなかったりした場合、クライアントはオリジンまたは別の代替サービスの使用にフォールバックしてもよい（MAY）。ただし、これはダウングレード攻撃の基礎となる可能性があり、代替サービスの強化されたセキュリティプロパティが失われることに注意してください。代替サービスへの接続が期待されるプロトコルをネゴシエートしない場合（例えば、ALPN が h2 のネゴシエートに失敗したり、h2c へのアップグレードリクエストが受け入れられなかったりする場合）、代替サービスへの接続は失敗したと見なされなければなりません（MUST）。