要約

  • JMAP Object Metadataの05版草案は10月28日、@typeとパディング付きの有効なbase64だけから成るBinary値を追加した。サーバーは正しい値を受け取った形のまま保存・返却する。
  • この値は深さゼロとして扱われるが、パッチや問い合わせの経路は内部をたどれず、文字列検索は一致しない。04版にこの節はなかった。

箱の所在は分かる。封印の内側は探せない

草案の例は、事業者の名前空間に32バイトの指紋を置く。存在を調べる問い合わせなら、その項目があると分かる。指紋の一部を文字列フィルターで探しても一致しない。base64の部分だけを書き換えようとするパッチも通らない。Binaryは小さなオブジェクトに見えて、プロトコル上は分割できない一つの値だ。

なぜこの器が要るのか。JSONの文字列はUnicodeのテキストであり、任意のバイト列そのものではない。追加された規定は二つのメンバー以外を認めず、不正なbase64をinvalidPropertiesで退ける。器を貫くパッチはinvalidPatchになる。サーバーは正確な保管を引き受けるが、バイト列の意味を決める立場にはならない。

意味を決めるのは名前空間の持ち主だ。事業者は、自分が管理する小文字のドメイン名を使えば、IANAへの事前登録なしに独自の名前空間を設けられる。サーバーは対象のデータ型でそれを許すか決める。共有メタデータは元のオブジェクトの閲覧権に従い、私用メタデータは認証された本人にひも付く。この権限構造は以前からあり、今回増えたのは内部に置けるバイトの形式だ。

深さゼロは容量ゼロではない。入れ子の深さと保存量は別の物差しで、草案はメタデータのクォータを求め、実装ごとのサイズ上限も認める。超過すればoverQuotaだ。通常の文字列についても、コストの高いテキストフィルターはサーバーが拒否できる。「検索できるメタデータ」を買うなら、実際のフィルター、値の型、容量の数え方まで聞かなければならない。

IETFの記録では、まだ作業部会のInternet-Draftだ。特定サーバーで書き込み、完全一致の読み戻し、内部への問い合わせの失敗、クォータ消費を示す記録が出れば運用上の判断が変わる。仕様の封印は明瞭だが、実装の棚卸しはこれからだ。

出典：05版；04版；IETFの状態。