[9]
RTSP
の
Proxy:
ヘッダーや
Proxy-Require:
ヘッダーは、
必要な機能を表します。
Require:
ヘッダー (RTSP)[10]
Require:
頭欄は、
ある必要な機能が実装されているかどうかを起源サーバーに問合せるために使用します。
[8] 起点鯖ではなく串に問合せるための同様の頭欄として
Proxy-Require
があります。
[13] 値は option tag です。
Proxy-Require:
ヘッダー (RTSP)[16]
Proxy-Require:
頭欄は、
ある必要な機能が実装されているかどうかをプロキシに問合せるために使用します。
[14]
option-tag
は、
Require:
や
Proxy-Require:
で使われる値です。
[15]
未対応のときの返答には Unsupported:
を使います。
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] これにより、全ての選択肢を両者が理解した場合は遅延なく, 選択肢を理解出来なかった (上記の) 場合には遅めるだけで、クライアント‐サーバー対話を進めるよう取り計らえます。
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 に登録するべきです。
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);