附属書 B. 'charset' パラメータの展開に関する考慮事項
B.1. ユーザーエージェント
'charset' を実装していないユーザーエージェントは、新しいパラメータを無視して、以前と同様に動作し続けます。
すでに UTF-8 エンコーディングをデフォルトにしているユーザーエージェントは、定義により 'charset' を実装しています。
他のユーザーエージェントは、デフォルトの動作を維持し、新しいパラメータを見たときに UTF-8 に切り替えることができます。
B.2. サーバー
認証情報で非 US-ASCII 文字をサポートしていないサーバーは、'charset' をサポートするために変更を必要としません。
非 US-ASCII 文字をサポートする必要があるが、UTF-8 文字エンコーディング方式を使用できないサーバーは影響を受けません。以前と同様に機能し続けます。
最後に、非 US-ASCII 文字をサポートする必要があり、UTF-8 文字エンコーディング方式を使用できるサーバーは、認証チャレンジで 'charset' パラメータを指定することでオプトインできます。'charset' パラメータを理解するクライアントは UTF-8 の使用を開始し、他のクライアントはデフォルトのエンコーディング、壊れた認証情報、または認証情報なしで送信し続けます。すべてのクライアントが UTF-8 をサポートするようにアップグレードされるまで、サーバーはリクエストで UTF-8 と "レガシー" エンコーディングの両方を見る可能性があります。UTF-8 として処理が失敗した場合 (UTF-8 としてのデコードの失敗またはユーザー ID/パスワードの不一致による)、サーバーはこれらのレガシークライアントに対応するために、以前にサポートされていたレガシーエンコーディングへのフォールバックを試みる可能性があります。暗黙的な再試行は慎重に行う必要があることに注意してください。たとえば、一部のサブシステムは繰り返されるログイン失敗を検出し、潜在的な認証情報推測攻撃として扱う場合があります。
B.3. なぜデフォルトのエンコーディングを単純に UTF-8 に切り替えないのか？
今日使用されているサイトは、ISO-8859-1 ([ISO-8859-1]) などのローカル文字エンコーディング方式をデフォルトにし、ユーザーエージェントがそのエンコーディングを使用することを期待しています。ユーザーエージェントが UTF-8 などの異なるエンコーディングに切り替えると、これらのサイトでの認証は機能しなくなります。
サイトは、User-Agent ヘッダーフィールド ([RFC7231]、第 5.5.3 節) を検査して、クライアントからどの文字エンコーディング方式を期待するかを決定する場合さえあることに注意してください。したがって、一部のユーザーエージェントには UTF-8 をサポートする一方で、他のユーザーエージェントには別のものをデフォルトにする可能性があります。後者のグループのユーザーエージェントは、これらのサーバーの大部分が常に UTF-8 を使用するようにアップグレードされるまで、今日行っていることを続ける必要があります。