[21] 拡張宣言は、
HTTPメッセージに適用される拡張を宣言するものです。
HTTPヘッダー
Man:, C-Man:,
Opt:, C-Opt:
は、拡張宣言を含めるものです。
[2] 拡張宣言は、当該メッセージに拡張が適用されることを示すとともに、 ヘッダー接頭辞の名前空間を予約するものです >>1。
[10] 拡張は、絶対URLかヘッダー名で識別します。 ヘッダー名は IETF 標準化過程RFC で定義されたヘッダーの名前でなければなりません。 >>1
[20] 拡張宣言は、必須のものと任意選択のものがあります >>19。
Man: と C-Man: には必須の拡張宣言を指定できます。
Opt: と C-Opt: には必須の拡張宣言を指定できます。
[23] 拡張宣言は、ホップ毎のものと末端対末端のものがあります >>19。
ホップ毎の拡張宣言は、当該HTTP接続にのみ適用されます >>19。
C-Man: と C-Opt: にはホップ毎の拡張宣言を指定できます >>19。
Man: と Opt: には末端対末端の拡張宣言を指定できます >>19。
[27] 各ヘッダーの値は、1つ以上の拡張宣言のリスト (#)
です >>19。
[4] 拡張宣言は、 " で括った絶対URLまたはヘッダー名の後に、
0個以上の ; と引数を指定したものです >>1。
[7] 引数は、名前のみか、名前と値を = で連結したものです >>1。
[26] 任意選択の拡張宣言は、どのHTTPメッセージにも指定できます >>19, >>34。
[28] C-Man:, C-Opt: およびこれらで宣言されたヘッダー接頭辞から始まるヘッダーの名前は、
Connection: に指定しなければなりません >>19。
[31] 必須の拡張宣言を含む要求を必須要求といいます。
必須要求の要求メソッドは M-* でなければなりません。 >>19
[35] 鯖は、必須の要求に対する応答で、または対応していることが事前に分かっている受信者に対してを除き、 必須の拡張宣言を送信してはなりません >>34。
[40] SSDP の M-SEARCH 要求でも
MAN: を使います >>39。
[42] SSDP の NOTIFY 要求で
OPT: やヘッダー接頭辞から始まるヘッダーを使った例も示されています >>41。
[25] 任意選択の拡張宣言の受信者は、拡張で指定された規則に従っても構いませんし、 拡張を無視しても構いません >>19, >>30。
[24] 必須の拡張宣言の受信者は、拡張で指定された規則に従わなければなりません >>19, >>30。従えない時は、 510
応答を返さなければなりません >>30。
[29] 末端対末端またはホップ毎の必須の拡張宣言を受信し、
その拡張をすべて理解して処理できた鯖は、
応答にそれぞれ Ext: と C-Ext:
を指定しなければなりません >>30。
[32] 必須の拡張宣言を処理する受信者でない串は、 転送時に拡張宣言を削除してはなりません >>30。
[36] クライアントが理解できない、または使いたくない必須の拡張宣言が応答に含まれていた場合には、
500 応答が返されたかのように扱うべきです >>34。
[12] 構文上 ns が最初の引数でなければならないようになっています >>1。
[14] 拡張の引数を使っても構いませんが、受信者が認識することは保証できません。 拡張の実現値データを伝えるために引数を使ってはなりません。 >>1
[38] RFC 4229 が RFC 2774 を出典にこれら4ヘッダーを状態「実験的」 でIANA登録簿に登録しています >>37。