[要約] RFC 2296は、HTTPリモートバリアント選択アルゴリズム（RVSA/1.0）に関する仕様です。このRFCの目的は、クライアントが複数のバリアントの中から最適なものを選択するためのアルゴリズムを提供することです。
Network Working Group K. Holtman
Request for Comments: 2296 TUE
Category: Experimental A. Mutz
Hewlett-Packard
March 1998
HTTP Remote Variant Selection Algorithm -- RVSA/1.0
HTTPリモートバリアント選択アルゴリズム-RVSA / 1.0
Status of this Memo
本文書の状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準も規定していません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
ABSTRACT
概要
HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0.
HTTPを使用すると、Webサイトの作成者は、同じ情報の複数のバージョンを1つのURLの下に置くことができます。透過的なコンテンツネゴシエーションは、URLにアクセスしたときに最適なバージョンを自動的に選択するメカニズムです。リモートバリアント選択アルゴリズムを使用して、透過的なネゴシエーションプロセスを高速化できます。このドキュメントでは、バージョン1.0のリモートバリアント選択アルゴリズムを定義しています。
TABLE OF CONTENTS
目次
1 Introduction...............................................2
2 Terminology and notation...................................2
3 The remote variant selection algorithm.....................2
3.1 Input....................................................2
3.2 Output...................................................3
3.3 Computing overall quality values.........................3
3.4 Definite and speculative quality values..................5
3.5 Determining the result...................................6
4 Use of the algorithm.......................................7
4.1 Using quality factors to rank preferences................7
4.2 Construction of short requests...........................8
4.2.1 Collapsing Accept- header elements.....................8
4.2.2 Omitting Accept- headers...............................9
4.2.3 Dynamically lengthening requests.......................9
4.3 Differences between the local and the remote algorithm..10
4.3.1 Avoiding major differences............................11
4.3.2 Working around minor differences......................11
5 Security and privacy considerations.......................11
6 Acknowledgments...........................................12
7 References................................................12
8 Authors' Addresses........................................12
9 Full Copyright Statement..................................13
1 Introduction
1はじめに
HTTP allows web site authors to put multiple versions (variants) of the same information under a single URL. Transparent content negotiation [2] is a mechanism for automatically selecting the best variant when the URL is accessed. A remote variant selection algorithm can be used by a HTTP server to choose a best variant on behalf of a negotiating user agent. The use of a remote algorithm can speed up the transparent negotiation process by eliminating a request-response round trip.
HTTPを使用すると、Webサイトの作成者は、同じ情報の複数のバージョン（バリアント）を1つのURLの下に置くことができます。透過的コンテンツネゴシエーション[2]は、URLにアクセスしたときに最適なバリアントを自動的に選択するメカニズムです。 HTTPサーバーは、リモートバリアント選択アルゴリズムを使用して、ネゴシエートするユーザーエージェントに代わって最適なバリアントを選択できます。リモートアルゴリズムを使用すると、要求と応答のラウンドトリップがなくなるため、透過的なネゴシエーションプロセスを高速化できます。
This document defines the remote variant selection algorithm with the version number 1.0. The algorithm computes whether the Accept-headers in the request contain sufficient information to allow a choice, and if so, which variant must be chosen.
このドキュメントでは、バージョン1.0のリモートバリアント選択アルゴリズムを定義しています。アルゴリズムは、リクエストのAcceptヘッダーに選択を可能にするのに十分な情報が含まれているかどうかを計算し、含まれている場合は、どのバリアントを選択する必要があるかを計算します。
2 Terminology and notation
2用語と表記
This specification uses the terminology and notation of the HTTP transparent content negotiation specification [2].
この仕様では、HTTP透過コンテンツネゴシエーション仕様[2]の用語と表記法を使用しています。
3 The remote variant selection algorithm
3リモートバリアント選択アルゴリズム
This section defines the remote variant selection algorithm with the version number 1.0. To implement this definition, a server MAY run any algorithm which gives equal results.
このセクションでは、バージョン1.0のリモートバリアント選択アルゴリズムを定義します。この定義を実装するために、サーバーは同等の結果が得られる任意のアルゴリズムを実行できます（MAY）。
Note: According to [2], servers are always free to return a list response instead of running a remote algorithm. Therefore, whenever a server may run a remote algorithm, it may also run a partial implementation of the algorithm, provided that the partial implementation always returns List_response when it cannot compute the real result.
注：[2]によれば、リモートアルゴリズムを実行する代わりに、サーバーは常にリスト応答を自由に返すことができます。したがって、サーバーがリモートアルゴリズムを実行するときはいつでも、実際の結果を計算できないときに部分的な実装が常にList_responseを返すことを条件に、アルゴリズムの部分的な実装を実行することもできます。
The algorithm is always run for a particular request on a particular transparently negotiable resource. It takes the following information as input.
アルゴリズムは、特定の透過的に交渉可能なリソース上の特定の要求に対して常に実行されます。以下の情報を入力として受け取ります。
1. The variant list of the resource, as present in the Alternates header of the resource.
1. リソースのAlternatesヘッダーにあるリソースのバリアントリスト。
2. (Partial) Information about capabilities and preferences of the user agent for this particular request, as given in the Accept-headers of the request.
2. （部分的）リクエストのAccept-headersにある、この特定のリクエストに対するユーザーエージェントの機能と設定に関する情報。
If a fallback variant description
フォールバックバリアントの説明
{"fallback.html"}
{"fallback.html"}
is present in the Alternates header, the algorithm MUST interpret it as the variant description
代替ヘッダーに存在する場合、アルゴリズムはそれをバリアントの説明として解釈する必要があります
{"fallback.html" 0.000001}
{"fallback.html" 0.000001}
The extremely low source quality value ensures that the fallback variant only gets chosen if all other options are exhausted.
ソース品質の値が非常に低いため、他のすべてのオプションを使い果たした場合にのみ、フォールバックバリアントが選択されます。
As its output, the remote variant selection algorithm and will yield the appropriate action to be performed. There are two possibilities:
その出力として、リモートバリアント選択アルゴリズムが実行され、適切なアクションが実行されます。 2つの可能性があります。
Choice_response
Choice_response
The Accept- headers contain sufficient information to make a choice on behalf of the user agent possible, and the best variant MAY be returned in a choice response.
Accept-ヘッダーには、ユーザーエージェントに代わって選択を行うのに十分な情報が含まれており、最良のバリアントが選択応答で返される場合があります。
List_response
List_response
The Accept- headers do not contain sufficient information to make a choice on behalf of the user agent possible. A list response MUST be returned, allowing the user agent to make the choice itself.
Accept-ヘッダーには、ユーザーエージェントに代わって選択を行うための十分な情報が含まれていません。リスト応答を返さなければならず、ユーザーエージェントはそれ自体で選択を行うことができます。
As a first step in the remote variant selection algorithm, the overall qualities of the individual variants in the list are computed.
リモートバリアント選択アルゴリズムの最初のステップとして、リスト内の個々のバリアントの全体的な品質が計算されます。
The overall quality Q of a variant is the value
バリアントの全体的な品質Qが値です
Q = round5( qs * qt * qc * ql * qf )
where round5 is a function which rounds a floating point value to 5 decimal places after the point, and where the factors qs, qt, qc, ql, and qf are determined as follows.
ここで、round5は浮動小数点値を小数点以下5桁に丸める関数であり、係数qs、qt、qc、ql、およびqfは次のように決定されます。
qs Is the source quality factor in the variant description.
qsバリアントの説明におけるソースの品質係数です。
qt The media type quality factor is 1 if there is no type attribute in the variant description, or if there is no Accept header in the request. Otherwise, it is the quality assigned by the Accept header to the media type in the type attribute.
qtバリアントの説明にtype属性がない場合、またはリクエストにAcceptヘッダーがない場合、メディアタイプの品質係数は1です。それ以外の場合は、Acceptヘッダーによってtype属性のメディアタイプに割り当てられる品質です。
Note: If a type is matched by none of the elements of an Accept header, the Accept header assigns the quality factor 0 to that type.
注：タイプがAcceptヘッダーのどのエレメントにも一致しない場合、Acceptヘッダーはそのタイプに品質係数0を割り当てます。
qc The charset quality factor is 1 if there is no charset attribute in the variant description, or if there is no Accept-Charset header in the request. Otherwise, the charset quality factor is the quality assigned by the Accept-Charset header to the charset in the charset attribute.
qcバリアントの説明に文字セット属性がない場合、またはリクエストにAccept-Charsetヘッダーがない場合、文字セット品質係数は1です。それ以外の場合、文字セット品質係数は、Accept-Charsetヘッダーによって文字セット属性の文字セットに割り当てられた品質です。
ql The language quality factor is 1 if there is no language attribute in the variant description, or if there is no Accept-Language header in the request. Otherwise, the language quality factor is the highest quality factor assigned by the Accept-Language header to any one of the languages listed in the language attribute.
qlバリアントの説明に言語属性がない場合、またはリクエストにAccept-Languageヘッダーがない場合、言語品質係数は1です。それ以外の場合、言語の品質係数は、Accept-Languageヘッダーによって言語属性にリストされている言語のいずれかに割り当てられた最高の品質係数です。
qf The features quality factor is 1 if there is no features attribute in the variant description, or if there is no Accept-Features header in the request. Otherwise, it is the quality degradation factor for the features attribute, see section 6.4 of [2].
qfバリアントの説明にfeatures属性がない場合、またはリクエストにAccept-Featuresヘッダーがない場合、機能の品質係数は1です。それ以外の場合は、features属性の品質低下要因です。[2]のセクション6.4を参照してください。
As an example, if a variant list contains the variant description
例として、バリアントリストにバリアントの説明が含まれている場合
{"paper.html.en" 0.7 {type text/html} {language fr}}
and if the request contains the Accept- headers
リクエストにAccept-ヘッダーが含まれている場合
Accept: text/html:q=1.0, */*:q=0.8
Accept-Language: en;q=1.0, fr;q=0.5
the remote variant selection algorithm will compute an overall quality for the variant as follows:
リモートバリアント選択アルゴリズムは、バリアントの全体的な品質を次のように計算します。
{"paper.html.fr" 0.7 {type text/html} {language fr}}
| | |
| | |
V V V
round5 ( 0.7 * 1.0 * 0.5 ) = 0.35000
With the above Accept- headers, the complete variant list
上記のAccept-ヘッダーを使用すると、完全なバリアントリスト
{"paper.html.en" 0.9 {type text/html} {language en}},
{"paper.html.fr" 0.7 {type text/html} {language fr}},
{"paper.ps.en" 1.0 {type application/postscript} {language en}}
would yield the following computations:
次の計算が得られます。
round5 ( qs * qt * qc * ql * qf ) = Q
--- --- --- --- --- -------
paper.html.en: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 = 0.90000
paper.html.fr: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 = 0.35000
paper.ps.en: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 = 0.80000
A computed overall quality value can be either definite or speculative. An overall quality value is definite if it was computed without using any wildcard characters '*' in the Accept- headers, and without the need to use the absence of a particular Accept- header. An overall quality value is speculative otherwise.
計算された全体的な品質値は、明確または推測のいずれかになります。 Accept-ヘッダーでワイルドカード文字「*」を使用せずに計算され、特定のAccept-ヘッダーがないことを使用する必要がない場合、全体的な品質値は明確です。それ以外の場合、全体的な品質値は推測です。
As an example, in the previous section, the quality values of paper.html.en and paper.html.fr are definite, and the quality value of paper.ps.en is speculative because the type application/postscript was matched to the range */*.
例として、前のセクションでは、タイプapplication / postscriptが範囲に一致したため、paper.html.enとpaper.html.frの品質値は明確であり、paper.ps.enの品質値は投機的です* / *。
Definiteness can be defined more formally as follows. An overall quality value Q is definite if the same quality value Q can be computed after the request message is changed in the following way:
明確さは、次のように、より正式に定義できます。要求メッセージが次のように変更された後に同じ品質値Qを計算できる場合、全体的な品質値Qは明確です。
1. If an Accept, Accept-Charset, Accept-Language, or Accept-Features header is missing from the request, add this header with an empty field.
1. Accept、Accept-Charset、Accept-Language、またはAccept-Featuresヘッダーがリクエストにない場合は、このヘッダーに空のフィールドを追加します。
2. Delete any media ranges containing a wildcard character '*' from the Accept header. Delete any wildcard '*' from the Accept-Charset, Accept-Language, and Accept-Features headers.
2. ワイルドカード文字「*」を含むメディア範囲をAcceptヘッダーから削除します。 Accept-Charset、Accept-Language、およびAccept-Featuresヘッダーからワイルドカード「*」を削除します。
As another example, the overall quality factor for the variant
別の例として、バリアントの全体的な品質係数
{"blah.html" 1 {language en-gb} {features blebber [x y]}}
is 1 and definite with the Accept- headers
1で、Accept-ヘッダーで明確です
Accept-Language: en-gb, fr
Accept-Features: blebber, x, !y, *
and
そして
Accept-Language: en, fr Accept-Features: blebber, x, *
Accept-Language：en、fr Accept-Features：blebber、x、*
The overall quality factor is still 1, but speculative, with the Accept- headers
全体的な品質係数は1のままですが、Accept-ヘッダーを使用して投機的です
Accept-language: en-gb, fr
Accept-Features: blebber, !y, *
and
そして
Accept-Language: fr, *
Accept-Features: blebber, x, !y, *
The best variant, as determined by the remote variant selection algorithm, is the one variant with the highest overall quality value, or, if there are multiple variants which share the highest overall quality, the first variant in the list with this value.
リモートバリアント選択アルゴリズムによって決定される最良のバリアントは、全体的な品質値が最も高い1つのバリアントです。または、全体的な品質が最も高いバリアントが複数ある場合は、リスト内の最初のバリアントがこの値になります。
The end result of the remote variant selection algorithm is Choice_response if all of the following conditions are met
次の条件がすべて満たされている場合、リモートバリアント選択アルゴリズムの最終結果はChoice_responseです。
a. the overall quality value of the best variant is greater than 0
a. 最良のバリアントの全体的な品質値が0より大きい
b. the overall quality value of the best variant is a definite quality value
b. 最良のバリアントの全体的な品質値は明確な品質値です
c. the variant resource is a neighbor of the negotiable resource. This last condition exists to ensure that a security-related restriction on the generation of choice responses is met, see sections 10.2 and 14.2 of [2].
c. バリアントリソースは、交渉可能なリソースのネイバーです。この最後の条件は、選択応答の生成に関するセキュリティ関連の制限が確実に満たされるようにするために存在します。[2]のセクション10.2および14.2を参照してください。
In all other cases, the end result is List_response.
他のすべての場合では、最終結果はList_responseです。
The requirement for definiteness above affects the interpretation of Accept- headers in a dramatic way. For example, it causes the remote algorithm to interpret the header
上記の明確さの要件は、Accept-ヘッダーの解釈に劇的な影響を与えます。たとえば、リモートアルゴリズムにヘッダーを解釈させる
Accept: image/gif;q=0.9, */*;q=1.0
as
なので
`I accept image/gif with a quality of 0.9, and assign quality factors up to 1.0 to other media types. If this information is insufficient to make a choice on my behalf, do not make a choice but send the list of variants'.
`0.9の品質のimage / gifを受け入れ、1.0までの品質係数を他のメディアタイプに割り当てます。この情報が私の代わりに選択を行うのに不十分な場合は、選択を行わず、バリエーションのリストを送信してください。
Without the requirement, the interpretation would have been
要件がなければ、解釈は
`I accept image/gif with a quality of 0.9, and all other media types with a quality of 1.0'.
`品質が0.9のimage / gifと、品質が1.0のその他すべてのメディアタイプを受け入れます。
4 Use of the algorithm
4アルゴリズムの使用
This section discusses how user agents can use the remote algorithm in an optimal way. This section is not normative, it is included for informational purposes only.
このセクションでは、ユーザーエージェントがリモートアルゴリズムを最適な方法で使用する方法について説明します。このセクションは規範的ではなく、情報提供のみを目的として含まれています。
Using quality factors, a user agent can not only rank the elements within a particular Accept- header, it can also express precedence relations between the different Accept- headers. Consider for example the following variant list:
ユーザーエージェントは品質係数を使用して、特定のAccept-ヘッダー内の要素をランク付けできるだけでなく、さまざまなAccept-ヘッダー間の優先関係を表すこともできます。たとえば、次のバリアントリストを考えてみます。
{"paper.english" 1.0 {language en} {charset ISO-8859-1}},
{"paper.greek" 1.0 {language el} {charset ISO-8859-7}}
and suppose that the user prefers "el" over "en", while the user agent can render "ISO-8859-1" with a higher quality than "ISO-8859- 7". If the Accept- headers are
また、ユーザーエージェントが「ISO-8859-1」を「ISO-8859-7」よりも高品質でレンダリングできる一方で、ユーザーが「en」よりも「el」を優先するとします。 Accept-ヘッダーが
Accept-Language: gr, en;q=0.8
Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.6, *
then the remote variant selection algorithm would choose the English variant, because this variant has the least overall quality degradation. But if the Accept- headers are
次に、リモートバリアント選択アルゴリズムは英語のバリアントを選択します。このバリアントは全体的な品質の低下が最も少ないためです。ただし、Accept-ヘッダーが
Accept-Language: gr, en;q=0.8
Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.95, *
then the algorithm would choose the Greek variant. In general, the Accept- header with the biggest spread between its quality factors gets the highest precedence. If a user agent allows the user to set the quality factors for some headers, while other factors are hard-coded, it should use a low spread on the hard-coded factors and a high spread on the user-supplied factors, so that the user settings take precedence over the built-in settings.
次に、アルゴリズムはギリシャのバリアントを選択します。一般に、品質係数間のばらつきが最も大きいAccept-ヘッダーが最も優先されます。ユーザーエージェントがユーザーに一部のヘッダーの品質係数の設定を許可し、他の係数がハードコードされている場合、ハードコードされた係数には低いスプレッドを使用し、ユーザー指定の係数には高いスプレッドを使用する必要があります。ユーザー設定は組み込み設定よりも優先されます。
In a request on a transparently negotiated resource, a user agent need not send a very long Accept- header, which lists all of its capabilities, to get optimal results. For example, instead of sending
透過的にネゴシエートされたリソースのリクエストでは、ユーザーエージェントは、すべての機能をリストする非常に長いAccept-ヘッダーを送信して、最適な結果を得る必要はありません。たとえば、送信する代わりに
Accept: image/gif;q=0.9, image/jpeg;q=0.8, image/png;q=1.0,
image/tiff;q=0.5, image/ief;q=0.5, image/x-xbitmap;q=0.8,
application/plugin1;q=1.0, application/plugin2;q=0.9
the user agent can send
ユーザーエージェントが送信できる
Accept: image/gif;q=0.9, */*;q=1.0
It can send this short header without running the risk of getting a choice response with, say, an inferior image/tiff variant. For example, with the variant list
たとえば、下位のイメージ/ tiffバリアントで選択応答を取得するリスクを冒すことなく、この短いヘッダーを送信できます。たとえば、バリアントリスト
{"x.gif" 1.0 {type image/gif}}, {"x.tiff" 1.0 {type image/tiff}},
{"x.gif" 1.0 {type image / gif}}、{"x.tiff" 1.0 {type image / tiff}}、
the remote algorithm will compute a definite overall quality of 0.9 for x.gif and a speculative overall quality value of 1.0 for x.tiff. As the best variant has a speculative quality value, the algorithm will not choose x.tiff, but return a list response, after which the selection algorithm of the user agent will correctly choose x.gif. The end result is the same as if the long Accept- header above had been sent.
リモートアルゴリズムは、x.gifについては0.9の明確な全体品質を計算し、x.tiffについては1.0の推測全体品質値を計算します。最良のバリアントには投機的な品質値があるため、アルゴリズムはx.tiffを選択せず、リスト応答を返します。その後、ユーザーエージェントの選択アルゴリズムはx.gifを正しく選択します。最終結果は、上記の長いAccept-ヘッダーが送信された場合と同じです。
Thus, user agents can vary the length of the Accept- headers to get an optimal tradeoff between the speed with which the first request is transmitted, and the chance that the remote algorithm has enough information to eliminate a second request.
したがって、ユーザーエージェントはAccept-ヘッダーの長さを変更して、最初の要求が送信される速度と、リモートアルゴリズムが2番目の要求を排除するのに十分な情報を持っている可能性との最適なトレードオフを得ることができます。
This section discusses how a long Accept- header which lists all capabilities and preferences can be safely made shorter. The remote variant selection algorithm is designed in such a way that it is always safe to shorten an Accept or Accept-Charset header by two taking two header elements `A;q=f' and `B;q=g' and replacing them by a single element `P;q=m' where P is a wildcard pattern that matches both A and B, and m is the maximum of f and g. Some examples are
このセクションでは、すべての機能と設定をリストする長いAccept-ヘッダーを安全に短くする方法について説明します。リモートバリアント選択アルゴリズムは、2つのヘッダー要素 `A; q = f 'と` B; q = g'を取り、それらを次のように置き換えることで、AcceptまたはAccept-Charsetヘッダーを常に安全に短縮できるように設計されています。単一の要素 `P; q = m 'ここで、PはAとBの両方に一致するワイルドカードパターンで、mはfとgの最大値です。いくつかの例は
text/html;q=1.0, text/plain;q=0.8 --> text/*;q=1.0
image/*;q=0.8, application/*;q=0.7 --> */*;q=0.8
iso-8859-5;q=1.0, unicode-1-1;q=0.8 --> *;q=1.0
Note that every `;q=1.0' above is optional, and can be omitted:
上記のすべての `; q = 1.0 'はオプションであり、省略できることに注意してください。
iso-8859-7;q=0.6, * --> *
For Accept-Language, it is safe to collapse all language ranges with the same primary tag into a wildcard:
Accept-Languageの場合、同じプライマリタグを持つすべての言語範囲をワイルドカードに縮小しても安全です。
en-us;q=0.9, en-gb;q=0.7, en;q=0.8, da --> *;q=0.9, da
It is also safe to collapse a language range into a wildcard, or to replace it by a wildcard, if its primary tag appears only once:
また、プライマリタグが1度しか出現しない場合は、言語の範囲をワイルドカードに折りたたんだり、ワイルドカードに置き換えたりしても安全です。
*;q=0.9, da --> *
Finally, in the Accept-Features header, every feature expression can be collapsed into a wildcard, or replaced by a wildcard:
最後に、Accept-Featuresヘッダーでは、すべての機能式をワイルドカードに折りたたむか、ワイルドカードに置き換えることができます。
colordepth!=5, * --> *
According to the HTTP/1.1 specification [1], the complete absence of an Accept header from the request is equivalent to the presence of `Accept: */*'. Thus, if the Accept header is collapsed to `Accept: */*', a user agent may omit it entirely. An Accept-Charset, Accept-Language, or Accept-Features header which only contains `*' may also be omitted.
HTTP / 1.1仕様[1]によると、リクエストにAcceptヘッダーが完全に存在しないことは、 `Accept：* / * 'が存在することと同じです。したがって、Acceptヘッダーが `Accept：* / * 'に縮小されている場合、ユーザーエージェントはそれを完全に省略できます。 `* 'のみを含むAccept-Charset、Accept-Language、またはAccept-Featuresヘッダーも省略できます。
In general, a user agent capable of transparent content negotiation can send short requests by default. Some short Accept- headers could be included for the benefit of existing servers which use HTTP/1.0 style negotiation (see section 4.2 of [2]). An example is
一般に、透過的なコンテンツネゴシエーションが可能なユーザーエージェントは、デフォルトで短いリクエストを送信できます。 HTTP / 1.0スタイルのネゴシエーションを使用する既存のサーバーのために、いくつかの短いAccept-ヘッダーを含めることができます（[2]のセクション4.2を参照）。例は
GET /paper HTTP/1.1
Host: x.org
User-Agent: WuxtaWeb/2.4
Negotiate: 1.0
Accept-Language: en, *;q=0.9
If the Accept- headers included in such a default request are not suitable as input to the remote variant selection algorithm, the user agent can disable the algorithm by sending `Negotiate: trans' instead of `Negotiate: 1.0'.
そのようなデフォルトのリクエストに含まれるAccept-ヘッダーがリモートバリアント選択アルゴリズムへの入力として適切でない場合、ユーザーエージェントは、「Negotiate：1.0」の代わりに「Negotiate：trans」を送信することにより、アルゴリズムを無効にできます。
If the user agent discovers, though the receipt of a list or choice response, that a particular origin server contains transparently negotiated resources, it could dynamically lengthen future requests to this server, for example to
ユーザーエージェントは、リストまたは選択の応答を受信しても、特定のオリジンサーバーに透過的にネゴシエートされたリソースが含まれていることを検出した場合、このサーバーへの将来の要求を動的に長くすることができます。
GET /paper/chapter1 HTTP/1.1
Host: x.org
User-Agent: WuxtaWeb/2.4
Negotiate: 1.0
Accept: text/html, application/postscript;q=0.8, */*
Accept-Language: en, fr;q=0.5, *;q=0.9
Accept-Features: tables, *
This will increase the chance that the remote variant selection algorithm will have sufficient information to choose on behalf of the user agent, thereby optimizing the negotiation process. A good strategy for dynamic extension would be to extend the headers with those media types, languages, charsets, and feature tags mentioned in the variant lists of past responses from the server.
これにより、リモートバリアント選択アルゴリズムがユーザーエージェントに代わって選択するのに十分な情報を持つ可能性が高まり、それによって交渉プロセスが最適化されます。動的拡張の適切な戦略は、サーバーからの過去の応答のバリアントリストで言及されているメディアタイプ、言語、文字セット、機能タグでヘッダーを拡張することです。
A user agent can only optimize content negotiation though the use of a remote algorithm if its local algorithm will generally make the same choice. If a user agent receives a choice response containing a variant X selected by the remote algorithm, while the local algorithm would have selected Y, the user agent has two options:
ユーザーエージェントは、ローカルアルゴリズムが一般的に同じ選択を行う場合は、リモートアルゴリズムを使用してのみコンテンツネゴシエーションを最適化できます。ユーザーエージェントがリモートアルゴリズムによって選択されたバリアントXを含む選択応答を受信し、ローカルアルゴリズムがYを選択した場合、ユーザーエージェントには2つのオプションがあります。
1. Retrieve Y in a subsequent request. This is sub-optimal because it takes time.
1. 後続のリクエストでYを取得します。これには時間がかかるため、最適ではありません。
2. Display X anyway. This is sub-optimal because it makes the end result of the negotiation process dependent on factors that can randomly change. For the next request on the same resource, and intermediate proxy cache could return a list response, which would cause the local algorithm to choose and retrieve Y instead of X. Compared to a stable representation, a representation which randomly switches between X and Y (say, the version with and without frames) has a very low subjective quality for most users.
2. とにかくXを表示します。これは、交渉プロセスの最終結果がランダムに変化する可能性のある要因に依存するため、最適ではありません。同じリソースに対する次のリクエストでは、中間プロキシキャッシュがリスト応答を返す可能性があり、ローカルアルゴリズムがXではなくYを選択して取得します。安定した表現と比較すると、XとYをランダムに切り替える表現（たとえば、フレームありとフレームなしのバージョン）は、ほとんどのユーザーにとって主観的な品質が非常に低くなります。
As both alternatives above are unattractive, a user agent should try to avoid the above situation altogether. The sections below discuss how this can be done.
上記のどちらの方法も魅力的ではないため、ユーザーエージェントは上記の状況を完全に回避するように努める必要があります。以下のセクションでは、これを行う方法について説明します。
If the user agent enables the remote algorithm in this specification, it should generally use a local algorithm which closely resembles the remote algorithm. The algorithm should for example also use multiplication to combine quality factors. If the user agent combines quality factors by addition, it would be more advantageous to define a new remote variant selection algorithm, with a new major version number, for use by this agent.
ユーザーエージェントがこの仕様でリモートアルゴリズムを有効にする場合、通常、リモートアルゴリズムによく似たローカルアルゴリズムを使用する必要があります。アルゴリズムでは、たとえば、乗算を使用して品質係数を組み合わせる必要もあります。ユーザーエージェントが品質係数を追加して組み合わせる場合、このエージェントで使用するために、新しいメジャーバージョン番号を持つ新しいリモートバリアント選択アルゴリズムを定義する方が有利です。
Even if a local algorithm uses multiplication to combine quality factors, it could use an extended quality formulae like
ローカルアルゴリズムが乗算を使用して品質係数を組み合わせる場合でも、次のような拡張品質式を使用できます。
Q = round5( qs * qt * qc * ql * qf ) * q_adjust
in order to account for special interdependencies between dimensions, which are due to limitations of the user agent. For example, if the user agent, for some reason, cannot handle the iso-8859-7 charset when rendering text/plain documents, the q_adjust factor would be 0 when the text/plain - iso-8859-7 combination is present in the variant description, and 1 otherwise.
ユーザーエージェントの制限による、ディメンション間の特別な相互依存を説明するため。たとえば、何らかの理由でユーザーエージェントがテキスト/プレーンドキュメントのレンダリング時にiso-8859-7文字セットを処理できない場合、テキスト/プレーン-iso-8859-7の組み合わせが存在する場合、q_adjust係数は0になります。バリアントの説明、それ以外の場合は1。
By selectively withholding information from the remote variant selection algorithm, the user agent can ensure that the remote algorithm will never make a choice if the local q_adjust is less than 1. For example, to prevent the remote algorithm from ever returning a text/plain - iso-8859-7 choice response, the user agent should take care to never produce a request which exactly specifies the quality factors of both text/plain and iso-8859-7. The omission of either factor from a request will cause the overall quality value of any text/plain - iso-8859-7 variant to be speculative, and variants with speculative quality values can never be returned in a choice response.
リモートバリアント選択アルゴリズムからの情報を選択的に保留することにより、ユーザーエージェントは、ローカルq_adjustが1未満の場合にリモートアルゴリズムが決して選択を行わないようにすることができます。たとえば、リモートアルゴリズムがtext / plainを返さないようにします- iso-8859-7選択応答の場合、ユーザーエージェントは、text / plainとiso-8859-7の両方の品質係数を正確に指定する要求を生成しないように注意する必要があります。リクエストからいずれかの要素を省略すると、text / plain-iso-8859-7バリアントの全体的な品質値が投機的になり、投機的な品質値を持つバリアントが選択応答で返されることはありません。
In general, if the local q_adjust does not equal 1 for a particular combination X - Y - Z, then a remote choice can be prevented by always omitting at least one of the elements of the combination from the Accept- headers, and adding a suitable wildcard pattern to match the omitted element, if such a pattern is not already present.
一般に、特定の組み合わせX-Y-Zのローカルq_adjustが1に等しくない場合、組み合わせの要素の少なくとも1つを常にAccept-ヘッダーから省略し、適切な省略された要素と一致するワイルドカードパターン（そのようなパターンがまだ存在しない場合）。
5 Security and privacy considerations
5セキュリティとプライバシーの考慮事項
This specification introduces no security and privacy considerations not already covered in [2]. See [2] for a discussion of privacy risks connected to the sending of Accept- headers.
この仕様は、[2]でまだカバーされていないセキュリティとプライバシーの考慮事項を導入していません。 Accept-ヘッダーの送信に関連するプライバシーリスクの説明については、[2]を参照してください。
6 Acknowledgments
6謝辞
Work on HTTP content negotiation has been done since at least 1993. The authors are unable to trace the origin of many of the ideas incorporated in this document. Many members of the HTTP working group have contributed to the negotiation model in this specification. The authors wish to thank the individuals who have commented on earlier versions of this document, including Brian Behlendorf, Daniel DuBois, Ted Hardie, Larry Masinter, and Roy T. Fielding.
HTTPコンテンツネゴシエーションに関する作業は、少なくとも1993年から行われています。著者は、このドキュメントに組み込まれている多くのアイデアの起源をたどることができません。 HTTPワーキンググループの多くのメンバーが、この仕様の交渉モデルに貢献しています。著者は、Brian Behlendorf、Daniel DuBois、Ted Hardie、Larry Masinter、Roy T. Fieldingなど、このドキュメントの以前のバージョンについてコメントしてくれた個人に感謝します。
7 References
7参考文献
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[1] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」、RFC 2068、1997年1月。
[2] Holtman, K., and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.
[2] Holtman、K。、およびA. Mutz、「Transparent Content Negotiation in HTTP」、RFC 2295、1998年3月。
8 Authors' Addresses
8著者のアドレス
Koen Holtman Technische Universiteit Eindhoven Postbus 513 Kamer HG 6.57 5600 MB Eindhoven (The Netherlands)
Koen Holtman Eindhoven University of Technology PO Box 513 Room HG 6.57 5600 MBアイントホーフェン（オランダ）
EMail: koen@win.tue.nl
Andrew H. Mutz Hewlett-Packard Company 1501 Page Mill Road 3U-3 Palo Alto CA 94304, USA
Andrew H. Mutz Hewlett-Packard Company 1501 Page Mill Road 3U-3 Palo Alto CA 94304、USA
Fax: +1 415 857 4691
EMail: mutz@hpl.hp.com
9 Full Copyright Statement
9完全な著作権声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。