1. 序論
~HTTP`~cache$は、 （ヒト, 自動化された~tool両者による）~debug法を援助するため，［ 自身が要請をどう取扱ったか説明する~header ］を応答に付加することが多い。 あいにく、 これらの~headerの意味論は，不明瞭なことが多く、 利用される［ 意味論, 構文 ］は，どちらも実装ごとに変わる。 ◎ To aid debugging (both by humans and automated tools), HTTP caches often append header fields to a response explaining how they handled the request. Unfortunately, the semantics of these header fields are often unclear, and both the semantics and syntax used vary between implementations.
この仕様は、 この目的~用の新たな~HTTP応答~headerとして， `Cache-Status$h を定義する。 ◎ This specification defines a new HTTP response header field, "Cache-Status", for this purpose with standardized syntax and semantics.
1.1. 表記上の規約
この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書は、 次に挙げる`各種~有構造~data型＠~STRUCTURED-FIELDS#types$ `STRUCTURED-FIELDS$r を利用して，構文と構文解析を指定する ⇒＃ `~sf~list$, `~sf文字列$, `~sf~token$, `~sf整数$, `~sf真偽値$ ◎ This document uses the following terminology from Section 3 of [STRUCTURED-FIELDS] to specify syntax and parsing: List, String, Token, Integer, and Boolean.
この文書は、 `HTTP$r, `HTTP-CACHING$r の各種用語も利用する。 ◎ This document also uses terminology from [HTTP] and [HTTP-CACHING].
2. `Cache-Status^h ~HTTP 応答~header
`Cache-Status^h ~HTTP応答~headerは、 ~cacheが［ 当の応答, それが応対した要請 ］をどう取扱ったかを指示する。 この~headerの構文は、 `STRUCTURED-FIELDS$r に適合する。 ◎ The Cache-Status HTTP response header field indicates how caches have handled that response and its corresponding request. The syntax of this header field conforms to [STRUCTURED-FIELDS].
その値は、 `~sf~list$である。 この~listを成す各~memberは、 要請を取扱った~cacheを表現する。 最初の~memberは，`生成元~server$に最も近い~cacheを表現し、 最後の~memberは，`~UA$に最も近い~cacheを表現する。 （~UAが使役している~cacheが値を付加したならば、 最後の~memberは，それを表現することになる）。 ◎ Its value is a List. Each member of the List represents a cache that has handled the request. The first member represents the cache closest to the origin server, and the last member represents the cache closest to the user (possibly including the user agent's cache itself if it appends a value).
応答に `Cache-Status^h ~headerをいつ追加するのが適切になるかは、 当の~cacheが決定する。 すべての応答に追加する~cacheもあれば、［ 特定的に環境設定されたとき／ 当の要請が~debug用の~modeを作動化する~headerを包含するとき ］に限り，そうする~cacheもあろう。 関係する`~securityの考慮点＠#security$も見よ。 ◎ Caches determine when it is appropriate to add the Cache-Status header field to a response. Some might add it to all responses, whereas others might only do so when specifically configured to, or when the request contains a header field that activates a debugging mode. See Section 6 for related security considerations.
`媒介者$は、 自身が局所的に`生成-$する応答に対しては — 当の応答が自身に格納-済みな応答に基づくとき（例： `304$st ／ `206$st ）を除いて — 自身が~cacheを使役する場合でも， `Cache-Status^h に~memberを付加するベキでない。 例えば， ある`~proxy$が不正形な要請に因り `400$st0 応答を`生成-$している場合、 `Cache-Status^h に値を追加しないことになる — その応答は、 `生成元~server$ではなく`~proxy$により`生成-$されたので。 ◎ An intermediary SHOULD NOT append a Cache-Status member to responses that it generates locally, even if that intermediary contains a cache, unless the generated response is based upon a stored response (e.g., 304 (Not Modified) and 206 (Partial Content) are both based upon a stored response). For example, a proxy generating a 400 response due to a malformed request will not add a Cache-Status value, because that response was generated by the proxy, not the origin server.
当の要請を取扱っている~cacheたちが成す連鎖~全体に対し，~debugすることを許容するため、 `Cache-Status^h ~headerに値を追加する~cacheは，既存の`~field値$を保全するベキである。 ◎ When adding a value to the Cache-Status header field, caches SHOULD preserve the existing field value, to allow debugging of the entire chain of caches handling the request.
この~listを成す各~memberは、 当の~memberを挿入した~cacheを識別する。 この識別子は、［ `~sf文字列$／`~sf~token$ ］でなければナラナイ。 これは、 配備に依存して，次に挙げるいずれにもなり得る ⇒＃ 製品や~serviceの名前（例： "`ExampleCache^c" や "`Example CDN^c" ）／ ~hostname（例： "`cache-3.example.com^c" ）／ ~IP~address／ 【当の~cacheにより】`生成-$された文字列 ◎ Each List member identifies the cache that inserted it, and this identifier MUST be a String or Token. Depending on the deployment, this might be a product or service name (e.g., "ExampleCache" or "Example CDN"), a hostname ("cache-3.example.com"), an IP address, or a generated string.
この~listを成す各~memberは、 `~sf~parameter群$を伴い得る — それは、 ~cacheによる当の要請の取扱いを述べる。 これらの各~parameter【`~sf~parameter$】は，`任意選択^2119であるが、 ~cacheには，アリな限り多くの情報を供することが奨励される。 ◎ Each member of the list can have parameters that describe that cache's handling of the request. While these parameters are OPTIONAL, caches are encouraged to provide as much information as possible.
この仕様は、 以下に挙げる~parameterを定義する。 ◎ This specification defines the following parameters.
2.1. `hit^c ~parameter
`hit^c ~parameterは、 `~sf真偽値$を値にとり， ~T ならば次を指示する ⇒ 当の要請は、 当の~cacheにより満足された — すなわち、 要請は回送されず，応答は当の~cacheから得された。 ◎ The value of "hit" is a Boolean that, when true, indicates that the request was satisfied by the cache; that is, it was not forwarded, and the response was obtained from the cache.
元々は`生成元~server$【！生成元】により生産されたが， ~cacheにより改変された応答（例えば，状態s~code `304$st0 ／ `206$st0 ）であっても、 （例えば検証~用に）回送されなかったならば，~hitと見なされる。 ◎ A response that was originally produced by the origin but was modified by the cache (for example, a 304 or 206 status code) is still considered a hit, as long as it did not go forward (e.g., for validation).
応答のうち~cache内にあったが，回送しない限り利用-可能でないものは （例：`非新鮮$／`部分的$であったため）、 ~hitとは見なされない。 `非新鮮$な応答であっても，回送することなく利用されたものは （例：`生成元~server$は可用でなかったため）、 ~hitと見なされ得ることに注意。 ◎ A response that was in cache but not able to be used without going forward (e.g., because it was stale or partial) is not considered a hit. Note that a stale response that is used without going forward (e.g., because the origin server is not available) can be considered a hit.
`hit$c と `fwd$c は、 排他的である — 各~list~memberには、 片方に限り出現するべきである。 ◎ "hit" and "fwd" are exclusive; only one of them should appear on each list member.
2.2. `fwd^c ~parameter
`fwd^c ~parameterは、 在るならば，［ 当の要請は、 `生成元~server$へ向けて回送された ］ことを指示する。 その値は、 `~sf~token$であり，なぜ回送されたかを指示する。 ◎ "fwd", when present, indicates that the request went forward towards the origin; its value is a Token that indicates why.
要請がなぜ回送されたかを説明するためとして、 次に挙げる~parameter値が定義される — 最も特定なものから順に【言い換えれば、優先~順に】： ◎ The following parameter values are defined to explain why the request went forward, from most specific to least:
- `bypass^c
- 当の~cacheは、 当の要請を取扱わないよう環境設定されていた。 ◎ The cache was configured to not handle this request.
- `method^c
- 当の要請の`~method$の意味論から、 当の要請を回送するよう要求された。 ◎ The request method's semantics require the request to be forwarded.
- `uri-miss^c
- 当の~cacheは、 当の要請の`~target~URI$【！要請~URI】に合致した応答を包含していなかった。 ◎ The cache did not contain any responses that matched the request URI.
- `vary-miss^c
- 当の~cacheは， 当の要請の`~target~URI$【！要請~URI】に合致した応答を包含していたが、［ 当の要請の~headerと格納-済み応答の `Vary$h ~header ］に基づいて応答を選定できなかった。 ◎ The cache contained a response that matched the request URI, but it could not select a response based upon this request's header fields and stored Vary header fields.
- `miss^c
- 当の~cacheは、 当の要請を満足するために利用できる応答を包含していなかった （これは、 実装が `uri-miss^c と `vary-miss^c を判別できないときに利用される）。 ◎ The cache did not contain any responses that could be used to satisfy this request (to be used when an implementation cannot distinguish between uri-miss and vary-miss).
- `request^c
- 当の~cacheは，当の要請~用に`新鮮$な応答を選定-可能であったが、 その利用は，当の要請の意味論（例： `Cache-Control$h 要請~指令）により許容されなかった。 ◎ The cache was able to select a fresh response for the request, but the request's semantics (e.g., Cache-Control request directives) did not allow its use.
- `stale^c
- 当の~cacheは，当の要請~用に応答を選定-可能であったが、 それは`非新鮮$であった。 ◎ The cache was able to select a response for the request, but it was stale.
- `partial^c
- 当の~cacheは，当の要請~用に`部分的$な応答を選定-可能であったが、 要請された範囲~すべてを包含するものは無かった （または、 当の要請は，完全な応答を要請していた【`範囲~要請$でなかった】）。 ◎ The cache was able to select a partial response for the request, but it did not contain all of the requested ranges (or the request was for the complete response).
~cacheは、 上に挙げた値のうち［ 自身に既知な最も特定な理由を表すもの ］を利用するベキである — 自身が実装することがアリな限りにおいて。 `HTTP-CACHING$r `~cacheからの応答の構築-法§ も見よ。 ◎ The most specific reason known to the cache SHOULD be used, to the extent that it is possible to implement. See also [HTTP-CACHING], Section 4.
2.3. `fwd-status^c ~parameter
`fwd-status^c ~parameterの値は，`~sf整数$であり、 当の~cacheが回送した要請に対し， `内方$にある次の~server【！the next-hop server】が返した応答の`状態s~code$ `HTTP$r 【！§ 15】を指示する。 この~parameterが有意義になるのは、 `fwd$c が在るときに限られる。 `fwd$c ~parameterが在るならば、 `fwd-status$c は無い場合の既定は， 当の応答~内に送信した状態s~codeになる。 ◎ The value of "fwd-status" is an Integer that indicates which status code (see [HTTP], Section 15) the next-hop server returned in response to the forwarded request. The fwd-status parameter is only meaningful when fwd is present. If fwd-status is not present but the fwd parameter is, it defaults to the status code sent in the response.
この~parameterは、 `内方$にある次の~server【！the next-hop server】が［ `条件付き要請$に対し `304$st 応答を送信した事例 ］と［ `範囲~要請$に対し `206$st 応答を送信した事例 ］とを判別するために有用になる。 ◎ This parameter is useful to distinguish cases when the next-hop server sends a 304 (Not Modified) response to a conditional request or a 206 (Partial Content) response because of a range request.
2.4. `ttl^c ~parameter
`ttl^c 【 “`time to live^en” 】~parameterの値は，`~sf整数$であり、 ~cacheにより計算された応答の残りの`鮮度~維持期間$を指示する。 値は、［ 当の~cacheが応答の`~header節$を送信し終える時点にアリな限り近い時点 ］に測定された【応答の`失効~時刻$までの】秒数として与えられる （ `HTTP-CACHING$r `鮮度~維持期間の計算＠~HTTPcache#calculating.freshness.lifetime§を見よ）。 これは、 当の~cacheにより — 例えば，［ 経験則（ `HTTP-CACHING$r `鮮度の経験的な計算-法＠~HTTPcache#heuristic.freshness§を見よ）／ 局所的な環境設定／ 他の要因 ］を通して — アテガわれた`鮮度$を含む。 これは、 負にもなり得る — その場合、 非新鮮~度【すなわち，`非新鮮$になってから経過した秒数】を指示する。 ◎ The value of "ttl" is an Integer that indicates the response's remaining freshness lifetime (see [HTTP-CACHING], Section 4.2.1) as calculated by the cache, as an integer number of seconds, measured as closely as possible to when the response header section is sent by the cache. This includes freshness assigned by the cache through, for example, heuristics (see [HTTP-CACHING], Section 4.2.2), local configuration, or other factors. It may be negative, to indicate staleness.
2.5. `stored^c ~parameter
`stored^c ~parameterの値は，`~sf真偽値$であり、 当の~cacheは，当の応答を格納した（ ~T の場合）かどうかを指示する （ `HTTP-CACHING$r `~cache内への応答の格納-法＠~HTTPcache#response.cacheability§を見よ）。 この~parameterが有意義になるのは、 `fwd$c が在るときに限られる。 ◎ The value of "stored" is a Boolean that indicates whether the cache stored the response (see [HTTP-CACHING], Section 3); a true value indicates that it did. The stored parameter is only meaningful when fwd is present.
2.6. `collapsed^c ~parameter
`collapsed^c ~parameterの値は，`~sf真偽値$であり、［ 当の要請は、 他の 1 個以上の回送された要請と一緒に`縮約-$された（ `HTTP-CACHING$r ）かどうか ］を指示する — ［ ~T ならば，当の応答は成功裡に再利用された／ ~F ならば，新たな要請を為す必要があった ］ことになる。 この~parameterが無い場合、 当の要請は，他と縮約されなかったことを指示する。 この~parameterが有意義になるのは、 `fwd$c が在るときに限られる。 ◎ The value of "collapsed" is a Boolean that indicates whether this request was collapsed together with one or more other forward requests (see [HTTP-CACHING], Section 4). If true, the response was successfully reused; if not, a new request had to be made. If not present, the request was not collapsed with others. The collapsed parameter is only meaningful when fwd is present.
2.7. `key^c ~parameter
`key^c ~parameterの値は，`~sf文字列$であり、 当の応答~用に利用された`~cache~key$ `HTTP-CACHING$r の表現を伝達する。 これは、 実装に特有になり得ることに注意。 ◎ The value of "key" is a String that conveys a representation of the cache key (see [HTTP-CACHING], Section 2) used for the response. Note that this may be implementation specific.
2.8. `detail^c ~parameter
`detail^c ~parameterの値は，［ `~sf文字列$／`~sf~token$ ］であり、 他の~parameterでは捕捉されなかった，追加的な情報 — 実装に特有な状態や，~cachingに関係する他の計量など — を伝達することを実装に許容する。 ◎ The value of "detail" is either a String or a Token that allows implementations to convey additional information not captured in other parameters, such as implementation-specific states or other caching-related metrics.
例えば： ◎ For example:
Cache-Status: ExampleCache; hit; detail=MEMORY
`detail^c ~parameterの意味論は、 常に，それを送信した~cacheに特有である — 別の~cacheからの `details^c ~parameterが同じ値をとる場合でも，同じものを意味するとは限らない。 ◎ The semantics of a detail parameter are always specific to the cache that sent it; even if a details parameter from another cache shares the same value, it might not mean the same thing.
この~parameterが【~cacheに特有になるよう】制限されているのは、 意図的である。 実装の［ 開発者／運用者 ］は、 追加的な情報を相互運用可能な流儀で伝達する必要がある場合には， 拡張~parameterを登録するか（ `4＠#register§ を見よ） 別の~headerを定義することが奨励される。 ◎ This parameter is intentionally limited. If an implementation's developer or operator needs to convey additional information in an interoperable fashion, they are encouraged to register extension parameters (see Section 4) or define another header field.
3. 例
最小限な~cache~hitの例： ◎ The following is an example of a minimal cache hit:
Cache-Status: ExampleCache; hit
気の利いた~cacheは、 もっと何か情報を与えることになろう： ◎ However, a polite cache will give some more information, e.g.:
Cache-Status: ExampleCache; hit; ttl=376
~hitしたが`非新鮮$な場合、 次のように，鮮度は負になる： ◎ A stale hit just has negative freshness, as in this example:
Cache-Status: ExampleCache; hit; ttl=-412
一方で、 完全な~missの例は： ◎ Whereas this is an example of a complete miss:
Cache-Status: ExampleCache; fwd=uri-miss
~missであったが，~backend~serverにより成功裡に検証されたときの例： ◎ This is an example of a miss that successfully validated on the backend server:
Cache-Status: ExampleCache; fwd=stale; fwd-status=304
~missであったが，別の要請と縮約されたときの例： ◎ This is an example of a miss that was collapsed with another request:
Cache-Status: ExampleCache; fwd=uri-miss; collapsed
~missであった, かつ~cacheは`縮約-$しようと試みたが、 できなかったときの例： ◎ This is an example of a miss that the cache attempted to collapse, but couldn't:
Cache-Status: ExampleCache; fwd=uri-miss; collapsed=?0
2 つの別々な~caching層を通ったときの例 — `生成元~server$に近い方の~cache（ `OriginCache^c ）は，以前の要請に対し格納-済み応答で応答し、 `~UA$に近い方の~cache（ "`CDN Company Here^c" ）は，その応答を格納して, 後でそれを再利用して現在の要請を満足した： ◎ The following is an example of going through two separate layers of caching, where the cache closest to the origin responded to an earlier request with a stored response, and a second cache stored that response and later reused it to satisfy the current request:
Cache-Status: OriginCache; hit; ttl=1100,
"CDN Company Here"; hit; ttl=545
3 層からなる~caching~systemを通ったときの例： ◎ The following is an example of going through a three-layer caching system, where＼
- `生成元~server$に最も近い~cache： `逆~proxy$（ `ReverseProxyCache^c ）であり、 そこでは，当の応答を~cacheから~serveした。 ◎ the closest to the origin is a reverse proxy (where the response was served from cache);＼
- その次の~cache： ~networkにより差挟まれた回送-~proxy（ `ForwardProxyCache^c ）であり、 そこでは， 当の要請の`~target~URI$に合致する応答を~cacheしてなかったので，当の要請を回送したことに加え、 当の要請を他と`縮約-$して，結果の応答を格納した。 ◎ the next is a forward proxy interposed by the network (where the request was forwarded because there wasn't any response cached with its URI, the request was collapsed with others, and the resulting response was stored);＼
- 利用者に最も近い~cache： ~browser~cache（ `BrowserCache^c ）であり、 そこでは，当の要請の`~target~URI$に合致する応答を~cacheしてなかった。 ◎ and the closest to the user is a browser cache (where there wasn't any response cached with the request's URI):
Cache-Status: ReverseProxyCache; hit Cache-Status: ForwardProxyCache; fwd=uri-miss; collapsed; stored Cache-Status: BrowserCache; fwd=uri-miss
4. 新たな `Cache-Status^h ~parameterの定義-法
`Cache-Status$h 用の新たな~parameterは、 `~HTTP Cache-Status ~registry^cite 内に登録することにより，定義できる。 ◎ New Cache-Status parameters can be defined by registering them in the "HTTP Cache-Status" registry.
登録~要請は、 `8126/4.5$rfc に従って，指名された専門家により考査された上で認可される。 仕様~文書は、 在った方が良いが，要求されてはいない。 ◎ Registration requests are reviewed and approved by a designated expert, per [RFC8126], Section 4.5. A specification document is appreciated but not required.
専門家（たち）は、 登録~要請を評価する際に，次に挙げる要因を考慮するべきである： ◎ The expert(s) should consider the following factors when evaluating requests:
- ~communityからの~feedback ◎ Community feedback
- 当の【~parameterの】値は、 不足なく きちんと定義されたかどうか ◎ If the value is sufficiently well defined
- ~parameterの名前【！値】は、［ ~vendor／応用／配備 ］に特有なものより，汎用なものの方が選好される。 汎用な名前【！値】が~community内で合意できなかった場合、 ~parameterの名前は，~~相応に特有な何かにするべきである （例：当の［ ~vendor／応用／配備 ］を識別する接頭辞を伴わせる）。 ◎ Generic parameters are preferred over vendor-specific, application-specific, or deployment-specific values. If a generic value cannot be agreed upon in the community, the parameter's name should be correspondingly specific (e.g., with a prefix that identifies the vendor, application, or deployment).
登録~要請は、 次の雛形を利用するべきである： ◎ Registration requests should use the following template:
- 名前 ⇒ `Cache-Status^h ~parameterの~key用の名前 — 構文上の要件は、 `~sf~key$ `STRUCTURED-FIELDS$r 【！§ 3.1.2】を見よ。 ◎ Name: • [a name for the Cache-Status parameter's key; see Section 3.1.2 of [STRUCTURED-FIELDS] for syntactic requirements]
- 型 ⇒ 当の~parameterの値の有構造~data型 — `~sf裸~item$ `STRUCTURED-FIELDS$r 【！§ 3.1.2】を見よ。 ◎ Type: • [the Structured Type of the parameter's value; see Section 3.1.2 of [STRUCTURED-FIELDS]]
- 記述 ⇒ 当の~parameterの意味論を成す記述 ◎ Description: • [a description of the parameter's semantics]
- 参照 ⇒ 当の~parameterを定義している仕様が可用ならば、 それへの参照 ◎ Reference: • [to a specification defining this parameter, if available]
登録~要請の送信-先の詳細は、 `当の~registry＠~IANA-a/http-cache-status$を見よ。 ◎ See the registry at <https://www.iana.org/assignments/http-cache-status> for details on where to send registration requests.
5. ~IANA考慮点
~IANAは、 `~HTTP Cache-Status ~registry＠~IANA-a/http-cache-status$cite を作成して，それを — `4＠#register§の手続-に従って — `2＠#field§にて定義した各~型で拡充した。 ◎ IANA has created the "HTTP Cache-Status" registry at <https://www.iana.org/assignments/http-cache-status> and populated it with the types defined in Section 2; see Section 4 for its associated procedures.
~IANAは、 `HTTP$r `~field名の登録＠~HTTPinfra#field.name.registration§ に定義される `~HTTP~field名~registry＠~IANA-a/http-fields$cite 内に，次の~entryを追加した： ◎ IANA has added the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in [HTTP], Section 18.4:
- ~field名 ⇒ `Cache-Status^h ◎ Field name: • Cache-Status
- 位置付け ⇒ 恒久的 ◎ Status: • permanent
- 参照 ⇒ ~RFC 9211 ◎ Reference: • RFC 9211
6. ~securityの考慮点
攻撃者は、 `Cache-Status$h 内の情報を利用して， ~cache（および他の~component）における挙動を探査したり， ~cacheを利用しているものの活動を推定し得る。 `Cache-Status^h ~headerは、 それ自体には，これらの~riskは無いこともあろうが， それを悪用している攻撃者を支援するものにはなり得る。 ◎ Attackers can use the information in Cache-Status to probe the behavior of the cache (and other components) and infer the activity of those using the cache. The Cache-Status header field may not create these risks on its own, but it can assist attackers in exploiting them.
例えば，ある~cacheが ある応答を格納したかどうか知ることは、 攻撃者が敏感な~dataに対し計時~攻撃を実行する助けになり得る。 ◎ For example, knowing if a cache has stored a response can help an attacker execute a timing attack on sensitive data.
加えて， `~cache~key$を公開することは、 攻撃者が~cache~keyに対する改変を解する助けになり得る — その結果，~cache汚染~攻撃を支援し得る。 詳細は `ENTANGLE$r を見よ。 ◎ Additionally, exposing the cache key can help an attacker understand modifications to the cache key, which may assist cache poisoning attacks. See [ENTANGLE] for details.
下層の~riskは、 それらの正確な資質に依存して，様々な技法で軽減できる （例： 暗号化と認証を利用する／ `~cache~key$に攻撃者が制御する~dataを内包しないようにする）。 当の~keyをボヤカすだけでは、 この~riskは軽減されないことに注意。 ◎ The underlying risks can be mitigated with a variety of techniques (e.g., using encryption and authentication and avoiding the inclusion of attacker-controlled data in the cache key), depending on their exact nature. Note that merely obfuscating the key does not mitigate this risk.
そのような攻撃を支援するのを避けるため、 `Cache-Status$h ~headerは，省略できる — 権限付与された~client以外には、［ ~headerを送信しない／敏感な情報（例： `key$c ~parameter）は送信しない ］など。 ◎ To avoid assisting such attacks, the Cache-Status header field can be omitted, only sent when the client is authorized to receive it, or sent with sensitive information (e.g., the key parameter) only when the client is authorized.