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 欄に札付けするのがよいです。

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.

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 に登録するべきです。