[2]
ヘッダー引数
typ
(type)
は、
JWS 応用が、
当該 JWS / JWE
全体の媒体型を宣言するために使うものです。
>>1, >>13
[11]
ヘッダー引数
cty
(content type)
は、
JWS 応用が、
保安された内容 (JWSペイロード >>1,
JWE の平文 >>13)
の媒体型を宣言するために使うものです。
>>1, >>13
[3]
typ は JWS を含み得る応用データ構造が複数種類のオブジェクトの種別たり得るような応用で、
cty は JWSペイロードに複数種類のオブジェクトが出現し得るような応用が使う想定です。
応用はこの値を使ってオブジェクトの種類を区別できます。
応用がオブジェクトの種類を既に知っている時は、
普通はこれを使いません。
>>1
[7] 値はRFC 2045 媒体型で、引数も利用できます。 >>1
[8]
値の先頭が application/ のとき、
他に / が含まれないなら、
この application/
を省略するべきです。
受信者は、
/ を含まない時、
application/
を先頭に補って解釈しなければなりません。
>>1
[15]
MIME型には通常 / をちょうど1個だけ含めることができます。
非標準の値で複数の / が含まれることも稀にありますが、
JOSE でそのような値が使われるとも思えません。
もし / が含まれ得るとしたら、それは引数値としてでしょうか。
[16]
typ
で
application/ が省略可能であるのは、
それ以外の型 (例えば image/*)
が使われることがおおよそ考え得ないからでしょう。
cty ではそうとも限りませんが、
省略可能なのは整合性のためでしょうか。
[18] 些細な事とはいえ、このわずかな違いのせいで既存の汎用的な MIME型の処理のプログラムはそのまま使えず、その前段、後段にちょっとした分岐を入れることになってしまいます。
application/ に属するものが圧倒的という現実はあります。
本来インターネットメール用だった MIME型が、
その構造を本格的に見直すことなく他の色々なデータ形式の記述に転用されたことによる不均衡といえます。
その不均衡に最適化しようとすると、多少アーキテクチャー的に美しくないとしても、
このような省略を認めるのが良いと考えられたのでしょう。
歪んだ設計が蓄積されてどんどん歪んでいく悪い症例です。application/ が小文字以外で表記される場合にも適用されると解するべきでしょう。
typはapplication/joseやapplication/jose+jsonになることが多そうです (がそれなら記述する必要はなさそうです)。 「JWS を使った○○応用のデータ形式」 のような記述を想定しているのでしょうが、 本当に需要はあるのでしょうか。