Resumen

  • La versión 10 de draft-ietf-mediaman-6838bis quedó disponible el 9 de septiembre de 2026 UTC. Sigue siendo un documento de trabajo del grupo Media Type Maintenance.
  • La versión 09 elegía reglas de fragmento según el éxito de una resolución en tiempo de ejecución. La 10 exige coherencia con la sintaxis que el sufijo realmente defina y deja los demás casos al tipo de medio.
  • El nuevo apartado para IANA enumera trece registros con una regla de tres casos que no puede activarse, porque los propios registros dicen que no existe una sintaxis de fragmento para ese sufijo.
  • Propongo un manifiesto de corrección distribuida que una la futura norma con las trece versiones anteriores y posteriores. Es análisis editorial de Daniel Kade, no una obligación de la draft.

La condición pedía un resultado antes de escoger la regla

La cuestión 93 describió el defecto con precisión. En la revisión 09, el procesador debía aplicar primero las reglas del sufijo cuando este definiera el tratamiento y resolviera con éxito el fragmento; de lo contrario, mandaban las reglas del tipo concreto. Pero saber si la resolución era exitosa exigía haber elegido y ejecutado antes uno de los dos marcos.

La revisión 10 evita ese circuito. Si el registro de un sufijo define sintaxis y semántica de fragmentos, el tipo que lo use debe ser compatible y no puede prohibir la sintaxis requerida. Si no las define, decide el tipo de medio. El cambio oficial entre versiones no conserva una prioridad condicionada por el resultado; la sustituye por una relación estática entre especificaciones.

La noticia se vuelve registral en la sección 8.2. Allí aparecen +json, +ber, +cbor, +der, +fastinfoset, +wbxml, +zip, +tlv, +json-seq, +sqlite3, +jwt, +gzip y +cbor-seq. El patrón de tres casos se remonta a RFC 6839 y fue copiado en registros posteriores. Sin embargo, cada una de esas trece fichas también declara que el sufijo carece de una sintaxis de fragmento definida. La nueva draft concluye que las ramas no pueden producirse y pide retirar ese texto, conservando el resto.

Trece filas convierten una errata lógica en una migración

El registro público de IANA mostraba fecha de actualización del 25 de junio de 2026 durante esta revisión. Tenía 24 entradas, política de Expert Review y dos expertos designados. La inspección de las trece entradas nombradas encontró en cada una las tres ramas y una declaración de ausencia de sintaxis. Esa fotografía no acusa un retraso: el texto 10 aún no es una autoridad publicada para ejecutar el cambio.

Aquí hay varias responsabilidades, no una cadena de mando única. Media Type Maintenance redacta la posible sustitución de RFC 6838. IANA mantiene las filas. Los expertos actúan conforme a la política del registro y al marco de RFC 8126. La IESG administra a los expertos de registros creados por la IETF y puede intervenir cuando corresponda. Una edición en el repositorio del grupo no equivale a una edición en la base pública.

También hay que evitar adelantar el estado. La cabecera del documento propone Best Current Practice; la ficha de Datatracker muestra por ahora que no hay estado RFC previsto. El grupo figura en Last Call desde la versión 06 de octubre de 2025. La versión 10 no es un RFC, no prueba una aprobación de la IESG y no demuestra que IANA haya tocado una sola fila.

El sufijo orienta; no homogeneiza todos los tipos

La terminación de un tipo permite reconocer una estructura subyacente. No autoriza a suponer que todos los objetos terminados en +json, +zip o +jwt admiten los mismos fragmentos ni comparten los mismos riesgos. La revisión 10 señala que la relación entre un tipo con sufijo y el nombre que resulta de quitarlo no se conoce solo por la etiqueta. La especificación del tipo conserva decisiones propias.

Por eso, borrar la rama imposible corrige orientación común y nada más. No crea sintaxis de fragmentos para las trece terminaciones. No cambia ejecutables, no certifica interoperabilidad y no prueba un incidente de seguridad. RFC 3986 explica el papel general del fragmento de una URI, pero no asigna significado a todos los formatos.

La versión 10 también incorporaría RFC 9694 y, si avanzara, reemplazaría ese RFC y RFC 6838. Esa consolidación es parte del contexto, no un atajo para declarar terminada la limpieza.

El manifiesto debe enumerar resultados, no intenciones

Un registro mínimo podría empezar por la identidad y la huella del documento final. Después anotaría la lista cerrada de sufijos, la identidad estable y la huella previa de cada ficha, la clase exacta de texto autorizado para borrar y una huella del contenido que debe permanecer. Al ejecutarse, sumaría la acción de IANA y su hora, la decisión del experto o de la IESG solo si se usó, las trece huellas posteriores y un enlace para rectificar o revertir una fila.

No se necesita publicar deliberación privada ni crear otro órgano de aprobación. Tampoco se pretende fijar el comportamiento de cada aplicación. El manifiesto prueba una propiedad más modesta: que la misma decisión llegó a cada destino y no arrastró datos ajenos.

La idea aplica la especificación mínima defendida por Heng Lu: compartir solo la evidencia indispensable para coordinar una transición, mientras las decisiones locales siguen en la especificación que les corresponde.

Estado de la evidencia

La ficha de Datatracker y su historial sitúan la revisión. La pull request 108 y el commit de integración muestran cómo entró el cambio. Ninguna fuente demuestra todavía el futuro resultado normativo u operativo.

Fuentes