Résumé

  • La révision 05 du projet JMAP Object Metadata, datée du 28 octobre, ajoute une valeur Binary composée exactement de @type et d’un champ base64 valide avec bourrage. Le serveur la conserve et la rend à l’identique.
  • Cette valeur compte pour une profondeur nulle, mais un chemin de modification ou de requête ne peut traverser son enveloppe. Les filtres textuels ne correspondent jamais à son contenu. La révision 04 ne contenait pas cette règle.

Une empreinte rangée sans moteur pour la retrouver

L’exemple du projet place une empreinte de 32 octets dans l’espace de nom d’un fournisseur. Le client peut vérifier que le champ existe. Il ne peut pas demander au filtre textuel du serveur de retrouver les octets de cette empreinte. Une modification visant seulement base64 échoue aussi : pour le protocole, la capsule entière est une valeur indivisible.

Ce choix répond à un problème matériel. JSON transporte du texte Unicode, alors qu’une application peut devoir conserver des octets arbitraires. Le nouveau paragraphe du projet impose une enveloppe stricte : deux membres, un codage base64 avec bourrage, aucun troisième champ. Un mauvais codage déclenche invalidProperties. La lecture rend exactement ce qui a été déposé. La recherche, elle, ne reçoit pas le droit d’ouvrir le paquet.

Qui donne un sens à ces octets ? Le propriétaire de l’espace de nom. Un fournisseur peut utiliser un nom de domaine qu’il contrôle, en minuscules, sans inscription préalable d’un nom auprès d’IANA. Le serveur choisit si le type d’objet accepte ces espaces de nom et quelle place il leur accorde. Les règles d’accès du modèle existaient déjà : les métadonnées partagées suivent la lecture de l’objet ; les métadonnées privées suivent l’utilisateur. La nouveauté du 28 octobre est la valeur binaire à l’intérieur de cette structure.

Profondeur zéro ne veut pas dire coût zéro. La limite de profondeur empêche l’imbrication ; le quota mesure séparément le stockage. Le projet demande aux serveurs de faire respecter un quota de métadonnées et permet des limites de taille propres à chaque mise en œuvre. Il autorise aussi le refus des filtres textuels ordinaires si leur coût est trop élevé. Un acheteur de « métadonnées interrogeables » doit donc demander quelles valeurs sont du texte, quelles valeurs sont Binary et quels filtres sont réellement fournis.

La fiche IETF indique un Internet-Draft de groupe de travail, pas un RFC achevé. Il manque encore une trace de serveur montrant l’écriture, la restitution exacte, l’échec des chemins internes et la consommation de quota. La capsule a une forme précise ; son usage réel reste à prouver.

Sources : révision 05 ; révision 04 ; statut IETF.