Resumen

  • La revisión 05 del borrador JMAP, de 28 de octubre, crea un valor Binary con solo dos miembros: @type y base64 válido con relleno. El servidor lo almacena y devuelve exactamente como llegó; un formato defectuoso se rechaza.
  • Ese valor se trata como una sola pieza de profundidad cero. Los parches y las rutas de consulta no alcanzan sus miembros, y los filtros de texto nunca coinciden con él. La revisión anterior no ofrecía esta pieza binaria.

La huella está en el cajón; la búsqueda no puede leerla

El ejemplo del documento guarda una huella de 32 bytes bajo un espacio de nombres de proveedor. Una consulta puede localizar la presencia de la propiedad. La misma consulta no puede buscar una secuencia de bytes dentro de la huella: las condiciones de texto exigen una cadena, y Binary no lo es. Tampoco sirve cambiar solo el miembro base64 mediante una ruta de parche. Para actualizar el dato hay que sustituir la pieza completa.

La propuesta llena un hueco real del formato: una cadena JSON lleva texto Unicode, no bytes arbitrarios. La sección nueva define una envoltura exacta, exige base64 con relleno y prohíbe miembros extra. El servidor responde invalidProperties ante una envoltura mal formada. Si un parche intenta atravesarla, responde invalidPatch. Ese rigor protege el valor almacenado; no convierte su contenido en una clave de búsqueda.

Hay tres responsables distintos detrás de una sola etiqueta. El dueño del espacio de nombres define qué significan los bytes. Un proveedor puede usar un dominio propio en minúsculas sin registrar primero un nombre en IANA. El servidor decide si admite espacios de proveedor en ese tipo de objeto y qué límites de almacenamiento aplica. Las reglas generales de acceso ya estaban en el borrador anterior: los metadatos compartidos siguen el permiso de lectura del objeto, mientras los privados pertenecen al usuario autenticado.

Profundidad cero tampoco equivale a almacenamiento gratuito. El límite de profundidad controla la estructura; las cuotas y los topes de tamaño se deciden aparte. El texto pide que los servidores apliquen cuotas a los metadatos y permite límites concretos según la implementación, con overQuota al excederlos. Incluso para cadenas normales, cuatro filtros de texto pueden rechazarse como unsupportedFilter por coste. Quien compre «metadatos consultables» necesita la lista de filtros reales y el tipo de cada campo, no solo una demostración de que se guardó algo.

El registro de IETF sigue mostrando un Internet-Draft de grupo de trabajo. Falta una prueba de servidor que escriba la cápsula, la lea byte por byte, pruebe el fallo de búsquedas internas y mida la cuota. Hasta entonces, el precinto está bien descrito y la estantería es una propuesta.

Fuentes: revisión 05; revisión 04; estado IETF.