Resumo

  • A revisão 05 do projeto JMAP, datada de 28 de outubro, acrescenta um valor Binary com exatamente @type e base64 válido com preenchimento. O servidor guarda e devolve a forma recebida; um invólucro malformado é recusado.
  • Embora conte como profundidade zero, o valor não permite acessar seus membros por patch ou consulta. Filtros de texto nunca combinam com ele. A revisão 04 ainda não continha essa seção.

O carimbo existe; a busca não o decifra

O próprio texto traz um exemplo de impressão digital de 32 bytes sob um namespace de fornecedor. Uma consulta de existência consegue localizar o campo. Procurar uma sequência de bytes dentro dele por filtro de texto não funciona. Tentar alterar só o membro base64 também falha: o protocolo trata o Binary inteiro como um valor só.

A razão técnica é simples. String JSON carrega texto Unicode, não qualquer sequência de bytes. A nova regra usa uma embalagem de dois membros, exige base64 com preenchimento e devolve invalidProperties para formato incorreto. Um patch que tenta atravessar a embalagem recebe invalidPatch. O servidor promete preservar o pacote exato; a semântica dos bytes fica com quem definiu o namespace.

Um fornecedor pode usar um domínio seu, em minúsculas, como identificador de namespace sem registrar antes um nome na IANA. O servidor escolhe se aquele tipo de objeto admite namespaces de fornecedores e quais limites de armazenamento aplica. Já as regras de leitura são anteriores à revisão: metadata compartilhado segue o acesso ao objeto, enquanto privateMetadata pertence ao usuário autenticado. A novidade é a cápsula de bytes dentro desse arranjo, não uma licença nova de acesso.

Profundidade zero não elimina o custo. O limite de profundidade mede aninhamento; cota mede espaço. O projeto pede que servidores controlem a cota de metadados e permite limites de tamanho próprios da implementação, com overQuota quando excedidos. Mesmo para strings comuns, filtros de texto podem ser recusados como unsupportedFilter se forem caros. Uma proposta comercial de «metadados pesquisáveis» precisa separar tipo, filtro disponível e espaço cobrado.

O registro do IETF ainda mostra um Internet-Draft de grupo de trabalho. Falta um teste de servidor que grave o valor, leia os bytes idênticos, tente as consultas internas e registre a cota consumida. A cápsula está desenhada; a operação ainda precisa de recibo.

Fontes: revisão 05; revisão 04; situação no IETF.