要約

  • CoAPのContent-Format識別子は、特定のContent Typeと任意のContent Codingを表し、意味上の登録から切り離された番号だけでは十分な情報になりません。
  • RFC 9876は先着順の経路を狭め、ほとんどの番号範囲に明確な専門家チェックを導入します。
  • 一時登録には明示的なライフサイクルが与えられ、64998と64999は文書用、65000-65535は運用ではなく実験用に区別されます。
  • 無効なパラメータ、未知の符号化、論理的な重複が、短くても誤解を招くプロトコル上の事実になることを防ぐ仕組みです。

CoAPのContent-Format識別子は、メディアタイプと、存在する場合にはコンテンツ符号化との組合せを表します。その整数を解釈するための情報はレジストリに置かれます。登録された組合せが無効、重複、または曖昧であれば、識別子は一意のプロトコル上の意味を指しません。

RFC 9876は、RFC 7252の12.3節にあった登録手続きを置き換えます。従来の問題は書類の不足ではなく、要求されたContent-TypeとContent Codingの組合せが意味的に有効かを明示的に確認する規則がなかったことです。この判断には、メディアタイプ、パラメータ、HTTP符号化の複数の登録情報が必要になる場合があります。申請欄が埋まっているかを確認する仕事と、有効で独立したペイロード表現かを判断する仕事は同じではありません。

新しい割当て表は、番号空間の希少性と審査の強さを対応させます。1バイトの0-255はExpert Reviewが必要です。256-9999はIETF ReviewまたはIESG ApprovalにExpert Reviewを組み合わせます。10000-19999と33000-64997もExpert Reviewです。先着順が残るのは20000-32999だけで、条件は限定されています。登録済みまたは登録承認済みのMedia Typeであり、パラメータもContent Codingもなく、そのMedia TypeがCoAPレジストリで未使用でなければなりません。条件を外れる申請は、先着順を拡大解釈せず、専門家審査のある範囲へ移ります。

専門家のチェックリストは文字列だけでなく意味を確認します。Content-TypeとContent Codingの組合せが既存でないこと、Media Typeに正式または条件を満たす暫定登録があること、パラメータ名と値が許可されていること、推奨形式に従うこと、Content CodingがHTTPのレジストリに存在することを検証します。既定値のパラメータやidentity符号化を明記しただけの論理的重複も、存在しないタイプや符号化を使うもっともらしい申請も、ここで見つけられます。

一時登録の扱いも整理されました。0-64997では、早期割当てや暫定Media Typeに結び付いたものを含め、一時的な登録が可能です。必要な手続きが完了し、Media Typeが恒久登録になれば、IANAは一時表示を外します。適用される手続きが失敗した場合や、対象となる暫定Media Typeが放棄された場合は、エントリを削除して識別子を未割当てに戻せます。一方、標準化手続きの完了を要件としない上位範囲には、RFCが示す例外が残ります。

残る境界も明文化されます。新しいMedia Type列が短いエントリを基礎登録へ結び付けます。64998と64999は文書例のための番号で、運用割当てではありません。65000-65535は実験用であり、運用展開には使えません。恒久的な意味、一時的な調整、例示、実験が同じ曖昧な領域に混ざらない設計です。

情報源