Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value)
priv-value = "header" / "session" / "user" / "none" / "critical"
/ token
つまりは
Privacy:header
とか
Privacy:header;session
みたいな例が記法としてはありと。下記の抜粋から
user,session,headerのいずれかまたは複数が一個は無くてはならない。（おのおの一度切りの出現のみ許容）
（ソフトフロント社の日本語版より抜粋）
header: ユーザーは、中継媒体の支援なしに情報を識別する、完全に消すこ
とのできないヘッダー(例えばViaとContact)を、プライバシーサービスが隠
すことを要求する。また、リクエストの発信元に関する個人情報を明かす
可能性があるサービスによって、不必要なヘッダーが追加されるべきでは
ない。
user: このプライバシーレベルは、おそらくユーザーエージェントは提供でき
ないことから、ユーザーレベルのプライバシー機能は(セクション5.3で議論
される通り)ネットワークによって提供されなければならないということを
伝達するために、一般的に、中継媒体によってのみ設定される。ユーザー
エージェントは、REGISTERリクエストのためにこのプライバシーを設定して
もよい[MAY]が、その他のリクエストのために「user」レベルプライバシー
を設定すべきではない[SHOULD]。
none: ユーザーは、以前に提供されたユーザーのプロフィールまたはサービス
のデフォルト動作に関わらず、プライバシーサービスがこのメッセージに
プライバシー機能を何も適用しないことを要求する。ユーザーエージェント
は、Privacyヘッダーが提示されないと、このメッセージに対してユーザー
の望まないなんらかのプライバシー機能を適用するプライバシーサービスを
通して、メッセージをルートするように強制される場合、このオプションを
指定できる。中継媒体はpriv-valueが「none」のPrivacyヘッダーを削除した
り、変更してはならない[MUST NOT]。ユーザーエージェントは「none」の値
を含むPrivacyヘッダーに、他のいかなるpriv-values(「critical」を含め)
を組み込んではならない[MUST NOT]。
critical: ユーザーは、このメッセージに対して要求されるプライバシーサー
ビスは重要であり、したがって、このプライバシーサービスがネットワーク
によって提供されない場合、このリクエストは拒否されるべきである、と主
張する。応答については、重要性は適切に管理できない。
session: ユーザーは、プライバシーサービスが、このメッセージで開始
される1つ以上のセッションの間(例えばSession Description Protocol
の[5]に記述されている)、匿名化を提供することを要求する。これは、普
通、セッションのトラフィックが始まるようなところからIPアドレスを隠す
だろう。セッションプライバシーが要求される場合、ユーザーエージェント
はメッセージ内のSDPボディは暗号化してはならない[MUST NOT]。エンドツー
エンドセッションの暗号化がない場合、セッションプライバシーを要求する
ことによって、重大なセキュリティ懸案が持ち上がるということに注意(セク
ション5.2を参照のこと)。
Privacyヘッダーが構築される場合、値「none」または、「critical」指定を受
けてもよい[MAY]、1個以上の「user」、「header」、「session」 (各々、出て
くるのは最高でも1度のみ出なければならない[MUST]) から構成されなければな
らない[MUST]。
priv-value = "header" / "session" / "user" / "none" / "critical"
/ token
つまりは
Privacy:header
とか
Privacy:header;session
みたいな例が記法としてはありと。下記の抜粋から
user,session,headerのいずれかまたは複数が一個は無くてはならない。（おのおの一度切りの出現のみ許容）
（ソフトフロント社の日本語版より抜粋）
header: ユーザーは、中継媒体の支援なしに情報を識別する、完全に消すこ
とのできないヘッダー(例えばViaとContact)を、プライバシーサービスが隠
すことを要求する。また、リクエストの発信元に関する個人情報を明かす
可能性があるサービスによって、不必要なヘッダーが追加されるべきでは
ない。
user: このプライバシーレベルは、おそらくユーザーエージェントは提供でき
ないことから、ユーザーレベルのプライバシー機能は(セクション5.3で議論
される通り)ネットワークによって提供されなければならないということを
伝達するために、一般的に、中継媒体によってのみ設定される。ユーザー
エージェントは、REGISTERリクエストのためにこのプライバシーを設定して
もよい[MAY]が、その他のリクエストのために「user」レベルプライバシー
を設定すべきではない[SHOULD]。
none: ユーザーは、以前に提供されたユーザーのプロフィールまたはサービス
のデフォルト動作に関わらず、プライバシーサービスがこのメッセージに
プライバシー機能を何も適用しないことを要求する。ユーザーエージェント
は、Privacyヘッダーが提示されないと、このメッセージに対してユーザー
の望まないなんらかのプライバシー機能を適用するプライバシーサービスを
通して、メッセージをルートするように強制される場合、このオプションを
指定できる。中継媒体はpriv-valueが「none」のPrivacyヘッダーを削除した
り、変更してはならない[MUST NOT]。ユーザーエージェントは「none」の値
を含むPrivacyヘッダーに、他のいかなるpriv-values(「critical」を含め)
を組み込んではならない[MUST NOT]。
critical: ユーザーは、このメッセージに対して要求されるプライバシーサー
ビスは重要であり、したがって、このプライバシーサービスがネットワーク
によって提供されない場合、このリクエストは拒否されるべきである、と主
張する。応答については、重要性は適切に管理できない。
session: ユーザーは、プライバシーサービスが、このメッセージで開始
される1つ以上のセッションの間(例えばSession Description Protocol
の[5]に記述されている)、匿名化を提供することを要求する。これは、普
通、セッションのトラフィックが始まるようなところからIPアドレスを隠す
だろう。セッションプライバシーが要求される場合、ユーザーエージェント
はメッセージ内のSDPボディは暗号化してはならない[MUST NOT]。エンドツー
エンドセッションの暗号化がない場合、セッションプライバシーを要求する
ことによって、重大なセキュリティ懸案が持ち上がるということに注意(セク
ション5.2を参照のこと)。
Privacyヘッダーが構築される場合、値「none」または、「critical」指定を受
けてもよい[MAY]、1個以上の「user」、「header」、「session」 (各々、出て
くるのは最高でも1度のみ出なければならない[MUST]) から構成されなければな
らない[MUST]。