Resumen

  • El W3C inició el 7 de agosto de 2026 el refinamiento formal de una nueva carta para WebAppSec, estimó el proceso hasta aproximadamente el 4 de septiembre y prorrogó la carta vigente hasta el 30 de octubre.
  • El borrador enumera 17 especificaciones normativas. Dieciséis dicen Expected completion: Undetermined; Fetch Metadata será incorporada a WHATWG Fetch, pero no lleva fecha.
  • “Por determinar” no significa tardío, abandonado o carente de recursos. El Proceso del W3C pide fechas esperadas cuando estén disponibles, no precisión inventada.
  • La autorización de la carta, la madurez de publicación, la actividad del repositorio, la evidencia de implementación y las fechas de la política de patentes son estados distintos.
  • Un registro de hitos por entregable debería identificar la próxima decisión competente, la dependencia, la clase de previsión, su responsable y la última revisión, aceptando desconocido como valor legítimo.

La prórroga mantiene autoridad, no completa el calendario

El aviso del 7 de agosto abrió un periodo de refinamiento que se esperaba prolongar unas cuatro semanas. Al mismo tiempo, el W3C llevó la vigencia de la carta actual hasta el 30 de octubre. El nuevo borrador propone durar dos años desde la futura convocatoria de participación.

Cada reloj responde a una pregunta diferente. El refinamiento ordena la discusión sobre el texto propuesto. La prórroga evita que caduque la autoridad presente. Los dos años delimitan un eventual mandato nuevo. Ninguno dice cuándo terminará una especificación.

Dentro de ese mandato propuesto aparecen diecisiete entregables normativos. Dieciséis tienen la fórmula explícita Expected completion: Undetermined. Fetch Metadata Request Headers no usa esa frase, pero sólo señala que el trabajo se incorporará a WHATWG Fetch, sin fecha.

El número no incluye tres entregables tentativos ni el trabajo no normativo. Tampoco convierte proyectos desiguales en una sola cohorte. Una especificación de mantenimiento, un mecanismo de seguridad reciente y un texto que depende de otro foro no pueden interpretarse con el mismo reloj.

Por ello, la ausencia de fecha no prueba dieciséis retrasos: no hay dieciséis compromisos calendarios incumplidos. La carencia observable es otra. Para saber qué podría cambiar el estado de cada fila, un lector debe recorrer páginas de publicación, repositorios, pruebas, discusiones de implementación y registros procesales separados.

Una propuesta visible aún no gobierna al grupo

La incidencia pública de estrategia se abrió en abril y continúa en refinamiento. Describe la ampliación de Web Cryptography Level 2, la inclusión normativa de Device Bound Session Credentials, una variante tentativa para inicio de sesión único y mayor coordinación con IETF y CFRG.

Las etiquetas de revisión horizontal completada son parte de la evidencia. No son la decisión que aprueba la carta. Lo mismo ocurre con la solicitud de cambios en el repositorio: su historial permite revisar cómo evolucionó el borrador, pero una fusión de código no sustituye la decisión institucional.

La descripción de la incidencia conserva un cálculo anterior que esperaba finalizar el refinamiento el 1 de agosto. El aviso formal posterior anuncia aproximadamente el 4 de septiembre. Una previsión fue revisada; ese solo hecho no demuestra incumplimiento del Proceso.

El Proceso del W3C separa el refinamiento que busca consenso de la revisión del Advisory Committee y de la Decisión del W3C cuando existen cambios importantes. La convocatoria de revisión debe destacar los cambios y explicar la disposición de los comentarios. La convocatoria de participación abre después el nuevo estado de autoridad.

La prórroga del mandato actual pertenece a otra clase de decisión. Mantiene la continuidad mientras se resuelve la propuesta. No incorpora en silencio los nuevos entregables ni transforma el borrador en obligación vigente.

No usar un estado como sustituto de otro

Una carta define el campo de acción, la duración, el método de decisión, las dependencias y los compromisos de participación y propiedad intelectual. El requisito de incluir hitos esperados “cuando estén disponibles” evita que el documento fabrique calendarios.

La página pública de publicaciones indica la madurez actual. Los repositorios exponen cambios editoriales y problemas abiertos. Las pruebas y las intenciones de implementar ofrecen evidencia para futuras transiciones. Las revisiones horizontales registran consideraciones de accesibilidad, privacidad, seguridad, internacionalización y arquitectura.

La Política de Patentes crea fechas adicionales. Los estados Adopted Draft y Exclusion Draft pueden delimitar oportunidades de exclusión y obligaciones de participantes. Una fecha jurídicamente relevante no es una fecha de terminación técnica.

El propio borrador remite a las publicaciones y a los repositorios para consultar esos estados. La decisión es razonable: el documento de autoridad no tiene que replicar toda la operación. Sin un índice común, sin embargo, los estados quedan repartidos y el mismo Undetermined puede significar dependencia externa, mantenimiento continuo, una decisión pendiente o una previsión que nadie publica.

La ambigüedad invita a dos exageraciones. Quien desea un lanzamiento puede leer la inclusión en una carta de dos años como promesa. Quien espera un fallo puede leer la falta de fecha como atraso. Ninguna conclusión nace de los datos disponibles.

Un registro que explique por qué no hay fecha

El registro propuesto tendría una fila estable por especificación. Anotaría el documento y repositorio, la madurez pública, la última transición formal, el estado relevante de patentes, la próxima decisión competente y cualquier dependencia o destino externo.

También mostraría revisión horizontal, pruebas e interés de implementación, más una clase de previsión: con fecha, ventana, ligada a dependencia, sólo mantenimiento o desconocida. La previsión tendría un responsable y una fecha de revisión. Una corrección añadiría una nueva entrada, sin borrar lo que se sabía antes.

Así, la línea de Fetch Metadata podría decir que el próximo cambio depende de una decisión en WHATWG Fetch, señalar quién verifica ese destino y cuándo volverá a revisarlo. La descripción no prometería que el W3C controla el calendario de otra comunidad.

Otra fila podría distinguir un documento mantenido bajo autoridad existente de una función nueva que todavía requiere dos intenciones de implementación, ensayos o revisión horizontal. La mención de Candidate Recommendation Snapshots tampoco se convertiría en una promesa de que todas las especificaciones llegarán a Recommendation.

Al terminar la carta, cada fila recibiría una disposición: transición completada, mantenimiento continuo, traslado, propuesta de nueva carta, salida del alcance o incertidumbre persistente. El objetivo no es eliminar lo desconocido, sino conservar quién lo revisó y qué decisión puede modificarlo.

Fuentes

  1. Aviso formal de refinamiento de WebAppSec
  2. Borrador público de la carta WebAppSec 2026
  3. Incidencia pública de renovación de WebAppSec
  4. Carta WebAppSec vigente
  5. Proceso del W3C
  6. Publicaciones de WebAppSec
  7. Solicitud pública de cambios de la carta
  8. Política de Patentes del W3C
  9. Heng Lu, The Policy Mirror