Resumen

  • La consulta de W3C del 14 de agosto proponía quitar WebHID, Web NFC, WebUSB, Web Bluetooth y Web Serial de los entregables tentativos de una carta aún no aprobada. Pedía comunicar cualquier inquietud antes del 28 de agosto.
  • Intel dijo dentro del plazo que le preocupaba retirar las cinco API. El 31 de agosto, el copresidente de Devices and Sensors comunicó que se habían planteado inquietudes y que, por eso, no se había alcanzado consenso.
  • El Steering Group de WHATWG tomó otra decisión: abrir el Peripheral APIs Workstream con las cinco especificaciones si no había objeciones a la CfC de W3C, o solo con Web Serial si las había.
  • WHATWG fusionó la propuesta completa el 29 de agosto. El registro de merge afirma que no hubo objeciones antes de su corte, a la vez que reconoce las inquietudes de Intel.
  • Un recibo de predicados entre foros debe fijar la pregunta de cada institución, las categorías de respuesta, el plazo y zona horaria, quién clasificó el mensaje y qué efecto produjo. Enlazar expedientes no transfiere competencia.

Antes de la bifurcación había una carta abierta

Las cinco API no estaban a punto de convertirse automáticamente en estándares. La carta propuesta de Devices and Sensors seguía marcada como [PROPOSED]. Web Bluetooth, Web Serial, WebUSB, Web NFC y WebHID aparecían como entregables tentativos y Draft Community Group Reports. Incorporarlas habría permitido trabajo en la Recommendation Track; no habría aprobado sus diseños ni garantizado su avance.

El aviso de revisión del 12 de junio abrió comentarios hasta el 17 de julio y reconoció discusiones sustantivas sin consenso. El 23 de julio se publicó una Formal Objection. Solicitaba dos soluciones alternativas: eliminar las cinco API o impedir su adopción y avance hasta documentar clases de explotación, formular mitigaciones normativas comprobables, obtener revisiones horizontales y explicar el tratamiento de cada riesgo.

Esas afirmaciones de seguridad pertenecen al objetor. No son conclusiones verificadas por W3C y este artículo no resuelve su mérito. El objeto comprobable es la respuesta institucional a la propuesta de eliminación.

Reilly Grant abrió el Call for Consensus del 14 de agosto con una pregunta concreta: ¿deben quitarse las cinco API de la lista para resolver la Formal Objection? El mensaje pedía contestar antes del 28 de agosto si existía «any concern» y señalaba que el silencio contaba como consentimiento. Por tanto, la entrada solicitada era más amplia que una objeción rotulada formalmente.

El archivo de W3C no contiene una votación binaria

Microsoft prefería conservar los entregables y tratar los riesgos, pero añadió una condición importante: no bloquearía el consenso para retirarlos. El workstream planteado en WHATWG hacía que la eliminación cambiara principalmente el foro, no que acabara el trabajo. Su respuesta distinguió también estar en una carta tentativa de recibir el aval del diseño o de alcanzar Recommendation.

Will Morgan favorecía la retención condicionada a una revisión del threat model. Sugirió retirar los entregables y recuperarlos si el workstream no aparecía en seis meses. François Daoust explicó el coste procedimental: volver a incorporarlos exigiría proponer una carta nueva. La lista de alcance no está bajo libre edición después de una decisión.

El 28 de agosto llegó el mensaje que hace visible la costura semántica. Anssi Kostiainen, con la función de chair expresamente apartada, dijo que Intel tenía inquietudes sobre retirar las cinco API. A juicio de Intel, mantenerlas dentro del grupo preservaría la revisión amplia y horizontal necesaria para una adopción diversa. El archivo recibió la respuesta a las 12:24 UTC, dentro de la fecha indicada.

Tres días después, Kostiainen actuó como copresidente y publicó el resultado de W3C: se habían planteado inquietudes; como resultado, no había consenso. El mensaje no atribuyó la ausencia de consenso exclusivamente a Intel. Tampoco mantuvo definitivamente las API, aprobó la carta o decidió la controversia de seguridad. El equipo de W3C debía planificar los pasos siguientes.

La salida correcta es «sin consenso para retirar», no «decisión final de conservar».

WHATWG miró el mismo archivo desde otra pregunta

La propuesta 264 de WHATWG llevaba abierta desde abril. Buscaba crear un Peripheral APIs Workstream para conectividad local, con las cinco especificaciones. Sus participantes habían discutido un alcance completo, un inicio con Web Serial, la relación con Devices and Sensors y el tratamiento de riesgos.

El acta del Steering Group del 25 de agosto fijó la rama. Tres de cuatro representantes escogieron comenzar el viernes con las cinco especificaciones si no había «objections to the W3C CfC». Si aparecía alguna objeción, el workstream nacería solo con Web Serial.

Esta no era la misma decisión que W3C. W3C debatía la eliminación de entregables de su carta. WHATWG definía el alcance inicial de su propio órgano. Sin embargo, WHATWG hizo que su resultado dependiera de una clasificación del proceso de W3C, y sustituyó en la condición la palabra concern por objection.

El 29 de agosto se fusionó el pull request. El comentario de merge documentó que no había objeciones a la CfC al final del horario laboral del viernes en PDT. Inmediatamente reconoció las inquietudes de Intel. El commit 7eb413b añadió al registro de WHATWG el workstream Peripheral APIs y cinco entradas: WebBluetooth, WebHID, WebNFC, WebSerial y WebUSB.

No se borró el mensaje. Se clasificó de una manera que no activó la rama «con objeciones» de WHATWG.

El mismo comentario anunció que las inquietudes deberían convertirse en issues cuando se creara el repositorio del workstream. Esa frase impide exagerar el estado: el commit prueba la entrada registral y su alcance. No prueba que todos los repositorios, issues, borradores, mitigaciones o revisiones ya estuvieran terminados.

La diferencia no demuestra irregularidad

Las instituciones pueden usar vocabularios propios. Según la Workstream Policy, una objeción sustantiva no resuelta de un Workstream Participant tiene un itinerario interno concreto. Un mensaje publicado en una lista de W3C no adquiere automáticamente ese carácter. Del otro lado, una decisión de WHATWG no resuelve la Formal Objection de W3C ni modifica una carta de W3C.

También diferían las proposiciones. Es posible oponerse a sacar un trabajo de W3C y, al mismo tiempo, apoyar que exista un workstream en WHATWG. Es posible aceptar la eliminación sin aprobar los diseños. Microsoft dejó escrito precisamente un estado mixto: preferencia por conservar, pero sin bloqueo. Reducir todo a votos afirmativos y negativos eliminaría la información más útil.

El defecto auditable no es la diversidad de reglas, sino la falta de una tabla entre ellas. Cuando un foro hace depender su acción de «ninguna objeción en el foro anterior», debería publicar si una inquietud cuenta, quién lo decide y qué ocurre con estados matizados. Sin esa tabla, el lector debe adivinar la traducción que activó la rama.

La tesis de Lu Heng en The Multi-Stakeholder Mirage ofrece una limitación adecuada: la participación puede aportar experiencia, advertencia u objeción, pero no se convierte por sí sola en mandato. El mensaje de Intel no gobernaba W3C ni WHATWG. Cada institución conservaba su decisión. Precisamente por eso debe exponer cómo trató la evidencia que recibió.

Un recibo para la condición compartida

El recibo empezaría con la proposición upstream: versión de la carta, cinco nombres, mensaje inicial, canal, plazo y la frase any concerns. Cada respuesta conservaría su etiqueta real y sus matices, incluido el compromiso de Microsoft de no bloquear. Message-ID y hora bastan para fijar el objeto sin revelar nada privado.

Después vendría el resultado de W3C: actor que cerró, hora, estado consensus was not reached, motivo publicado y siguiente autoridad competente. Una decisión futura de carta se añadiría como sucesora; no sustituiría retrospectivamente el cierre del 31 de agosto.

La mitad de WHATWG copiaría la condición de cinco-versus-uno, su zona horaria, el Steering Group que la adoptó y la regla de mapeo. Tendría que responder de forma directa: ¿por qué la inquietud reconocida no fue una objeción para esta rama? El merge ofrece la clasificación puntual, pero no formula una política reutilizable.

La acción final señalaría el pull request, el commit y los cinco registros. Las futuras issues y publicaciones tendrían estados propios. Un campo de no herencia completaría el expediente: ningún resultado de W3C autoriza a WHATWG, y ningún merge de WHATWG decide la carta de W3C.

Frontera de la evidencia

La página pública de Devices and Sensors seguía diciendo «Chartered until 31 August 2026» cuando la carta sucesora continuaba propuesta. Es una señal para vigilar, no evidencia de que el grupo haya dejado de operar o de que exista una resolución final no publicada.

Tampoco hay un veredicto técnico. La Formal Objection atribuye riesgos concretos; otras respuestas consideran que pueden trabajarse con revisión y mitigaciones. Abrir un workstream no certifica seguridad. No lograr consenso para retirar no convierte los cinco diseños en Recomendaciones.

La conclusión se limita al expediente: W3C pidió inquietudes y las citó para cerrar sin consenso. WHATWG buscó objeciones para su propia bifurcación, reconoció la inquietud de Intel y dio por cumplida la ausencia de objeciones. Ambas decisiones pueden ser defendibles. El puente semántico debería ser tan público como sus extremos.

Fuentes