7.4.1.4.1節を参照)。拡張についての仕様を提供する。素材を採用して編集したものである。プロトコルメッセージフォーマットによって提供されている機能を拡張することに焦点を当てる。追加のような他の論点は、見送られた。本書中に定義された拡張種別は、下記のとおり。サーバ宛に、問い合わせているそのサーバの名前を提供できるようにする。この機能は、基礎となっている(underlying)単一のネットワークアドレスにおいて複数の「バーチャル」サーバをホストするサーバへのセキュアな接続を容易にするために、渇望されている。クライアントおよびサーバが送られるべき最大フラグメント長を交渉できるようにする。この機能は、何らかのクライアントにおけるメモリ制約、および、何らかのアクセスネットワークにおける帯域制約の結果として、渇望されている。利用を交渉できるようにする。この機能は、制約のあるクライアント上のメモリを節約するために、渇望されている。ルート鍵を保持しているか?」を示すことができるようにする。クライアントを巻き込む複数のハンドシェイクの失敗を防ぐために、渇望されている。利用を交渉できるようにする。この機能は、制約されたアクセスネットワークにおける帯域を節約する(conserve)ために、渇望されている。おいて送ること」を交渉できるようにする。制約されたアクセスネットワーク越しに送ることを避け、ひいては帯域を節約するために、渇望されている。サーバは、本書中に記述された拡張を使う可能性がある。この拡張は、下位互換となるように設計された。versa)」を意味する。計算中に含まれなければならない(MUST)こと」に注意。「本書中に定義されているすべての拡張は、あるセッションが開始されるときのみ、関連すること」にも注意。受容するか否か?」を知らない。それゆえ、それは、中断を試みるのでないならば送った拡張と同一のものを送る必要がある(SHOULD)。:サーバ名表示拡張は、「3章に記述されているようにセッションを再開会するか否か?」を判断するとき、そのサーバによって使われる可能性がある(MAY)。送らなければならない(MUST)。セッションに適用される。記述されたように解釈されるべきものである。"CertificateStatus")の利用を規定する。8章に記述されている。メッセージ構造体は、下記のようになる。クライアント用に、サーバ宛にクライアントがコンタクトしようとしているサーバの名前を伝えるためのメカニズムを提供しない。これは、クライアント用に単一の基盤となっている(underlying)ネットワークアドレスで複数の「バーチャル」サーバをホストするサーバへのセキュアな接続を容易にするために、この情報を提供するために渇望される可能性がある。拡張を含む可能性がある(MAY)。納めるものとする(SHALL)。これは、下記のとおり。拡張は解釈できるが、サーバ名を解釈できない場合、そのサーバは、(次の)ふたつにひとつのアクションをとる必要がある(SHOULD)。送ることによって、そのハンドシェイクを中断するか、あるいは、そのハンドシェイクを続けるか、のいずれかである。RECOMMENDED)。識別(identification)を行うとき、そのクライアントアプリケーションが「その通信を続けるか否か?」を判断する必要がある時点で明らかになる。警告についての情報を入手可能にすることが強く薦められる。このような情報は、診断(diagnostic)目的のために有用である可能性がある。複数の名前を許容していた。実際、現在のクライアント実装は、ひとつだけ名前を送り、そのクライアントは、必ずしもそのサーバが選択した名前を見つけ出せるとは限らない。複数の名前は、今は禁止されている。