Require

Require: ヘッダー, Proxy-Require: ヘッダー, option tag (RTSP)

[9] RTSPProxy: ヘッダーProxy-Require: ヘッダーは、 必要な機能を表します。

Require: ヘッダー (RTSP)

[10] Require: 頭欄は、 ある必要な機能が実装されているかどうかを起源サーバー問合せるために使用します。

[8] 起点鯖ではなくに問合せるための同様の頭欄として Proxy-Require があります。

構文

[13] 値は option tag です。

Proxy-Require: ヘッダー (RTSP)

[16] Proxy-Require: 頭欄は、 ある必要な機能が実装されているかどうかをプロキシ問合せるために使用します。

[17] ではなく起源サーバーに問合せるための同様の頭欄として Require があります。

option tag (RTSP)

[14] option-tag は、 Require:Proxy-Require: で使われる値です。

関連

[15] 未対応のときの返答には Unsupported: を使います。

[11] HTTP で似たような頭欄として Man: があります。

歴史

[7] RFC 2326 (RTSP) 12.32 Require

The Require header is used by clients to query the server about options that it may or may not support. The server MUST respond to this header by using the Unsupported header to negatively acknowledge those options which are NOT supported.

[1] Require 頭はクライアントがサーバーに、対応しているかもしれないしいないかもしれない選択肢について問い合わせるのに使います。 サーバーは対応していない選択肢について Unsupported 頭を使って否定応答しなければなりません

This is to make sure that the client-server interaction will proceed without delay when all options are understood by both sides, and only slow down if options are not understood (as in the case above). For a well-matched client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes state ambiguity when the client requires features that the server does not understand.

[2] これにより、全ての選択肢を両者が理解した場合は遅延なく, 選択肢を理解出来なかった (上記の) 場合には遅めるだけで、クライアント‐サーバー対話を進めるよう取り計らえます。

  • [3] Require = "Require" ":" 1#option-tag

[4]

Example:

     C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
             CSeq: 302
             Require: funky-feature
             Funky-Parameter: funkystuff

     S->C:   RTSP/1.0 551 Option not supported
             CSeq: 302
             Unsupported: funky-feature
     C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
             CSeq: 303
     S->C:   RTSP/1.0 200 OK
             CSeq: 303

In this example, "funky-feature" is the feature tag which indicates to the client that the fictional Funky-Parameter field is required. The relationship between "funky-feature" and Funky-Parameter is not communicated via the RTSP exchange, since that relationship is an immutable property of "funky-feature" and thus should not be transmitted with every exchange.

[5] この例では、 "funky-feature" が架空の Funky-Parameter 欄が必須であるとクライアントに示す機能札です。 "funky-feature"Funky-Parameter の関係については RTSP 交換では伝達されません。 なぜならこの関係は "funky-feature" の不変の属性であって毎度の交換で伝送しなくても良いからです。

Proxies and other intermediary devices SHOULD ignore features that are not understood in this field. If a particular extension requires that intermediate devices support it, the extension should be tagged in the Proxy-Require field instead (see Section 12.27).

[6] 串及び他の中間機器はこの欄にある理解出来ない機能を無視するのが良いです。 特定の拡張に中間機器が対応する必要がある時は、その拡張は代わりに Proxy-Require 欄に札付けするのがよいです。

[18] RFC 2326 12.27 Proxy-Require

The Proxy-Require header is used to indicate proxy-sensitive features that MUST be supported by the proxy. Any Proxy-Require header features that are not supported by the proxy MUST be negatively acknowledged by the proxy to the client if not supported. Servers should treat this field identically to the Require field.

[19] Proxy-Require 頭は、串が対応していなければならない串敏感機能を示すのに使います。 串が対応していないどの Proxy-Require 頭機能についても、串はクライアントに否定応答しなければなりません。 サーバーはこの欄を Require 欄と等しいと扱うのが良いです。

See Section 12.32 for more details on the mechanics of this message and a usage example.

[12] RFC 2326 (RTSP) 3.8 Option Tags

Option tags are unique identifiers used to designate new options in RTSP. These tags are used in Require (Section 12.32) and Proxy-Require (Section 12.27) header fields.

選択肢札は RTSP における新たな選択肢を指示するのに使う固有識別子です。 この札は Require 頭欄や Proxy-Require 頭欄で使います。

Syntax:

  • option-tag = 1*xchar

The creator of a new RTSP option should either prefix the option with a reverse domain name (e.g., "com.foo.mynewfeature" is an apt name for a feature whose inventor can be reached at "foo.com"), or register the new option with the Internet Assigned Numbers Authority (IANA).

新しい RTSP 選択肢の作者は選択肢の接頭辞を逆ドメイン名 (例えば、その発明者が foo.com で到達できる機能の名前は com.foo.mynewfeature) にするか、又は新しい選択肢を IANA に登録するべきです。

3.8.1 Registering New Option Tags with IANA

When registering a new RTSP option, the following information should be provided:

新しい RTSP 選択肢を登録する時は、 次の情報を提供するべきです。

  • Name and description of option. The name may be of any length, but SHOULD be no more than twenty characters long. The name MUST not contain any spaces, control characters or periods.
  • Indication of who has change control over the option (for example, IETF, ISO, ITU-T, other international standardization bodies, a consortium or a particular company or group of companies);
  • A reference to a further description, if available, for example (in order of preference) an RFC, a published paper, a patent filing, a technical report, documented source code or a computer manual;
  • For proprietary options, contact information (postal and email address);
  • 選択肢の名前及び説明。名前は任意の長さで構いませんが、20文字より長くしないべきです。名前は間隔制御文字終止符を含んでいてはなりません
  • その選択肢の変更制御権保持者の標示 (例えば、 IETF, ISO, ITU-T, その他国際標準化団体, 業界団体, 特定企業あるいは企業集団)。
  • より詳細な説明が利用可能であればそれへの参照。 例えば RFC, 出版済み論文, 特許届出, 技術報告, 文書化されたソース・コードあるいは計算機取扱説明書。
  • 独占的な選択肢には、問合せ先 (郵便・電子メイルの宛先)。

メモ