Resumen

  • El RFC 1590, de marzo de 1994, amplió los antiguos «tipos MIME» a «tipos de medios» utilizables entre aplicaciones. El proponente enviaba el nombre a ietf-types; tras dos semanas podía solicitar su registro ante IANA y la asignación de un OID.
  • El registro podía reunir un vocabulario amplio y común. Un lector de correo, cuyos destinatarios tenían capacidades desconocidas, podía seguir recomendando un grupo reducido de formatos habituales mediante orientación propia de esa aplicación.

El problema era el nombre que todos iban a repetir

Una foto, una grabación y un documento de un programa nuevo llegan a distintos sistemas. Si cada uno inventa etiquetas a su gusto, un mismo objeto acaba con varios nombres y dos objetos distintos pueden reclamar el mismo. El daño parece pequeño mientras los programas viven separados. Aparece de golpe cuando intercambian archivos y los nombres ya están grabados en código y manuales.

El RFC 1521 había dado a MIME una forma de describir los cuerpos del correo. Allí se valoraba la prudencia: el remitente de un mensaje asíncrono suele desconocer lo que puede mostrar el destinatario, de modo que usar unos pocos tipos comunes favorece la lectura. Fuera del correo, las mismas etiquetas empezaban a servir para otros intercambios. Jon Postel explicó en el RFC 1590 que la lista de nombres podía crecer sin obligar a cada lector de correo a adoptar todos los formatos que aparecieran.

El cambio de vocabulario fue deliberado. Los «tipos MIME» pasaron a llamarse «tipos de medios». Tipo y subtipo formaban una designación reutilizable. El registro respondía a la pregunta «¿de qué formato hablamos?»; cada aplicación respondía a «¿puedo manejarlo aquí?». Separar las dos preguntas evitaba que las capacidades de un programa concreto gobernaran el diccionario de todos.

El trámite comenzaba en ietf-types. El aspirante publicaba el tipo y subtipo; mientras era propuesta, el subtipo llevaba la forma x-. La comunidad podía discutir si el nombre era claro, si las referencias precisaban la versión o el perfil, qué identificador de objeto correspondía y qué riesgos se conocían. También cabía decir que el formato estaba pensado para un uso limitado. Esa discusión abierta ocurría antes de que una etiqueta se instalara silenciosamente en muchas máquinas.

Pasadas dos semanas, el proponente enviaba la solicitud a IANA. Tras un período razonable de revisión, el proceso descrito en el RFC llevaba al registro, a un OID bajo la rama de IANA y a una entrada disponible públicamente. El formulario pedía tipo, subtipo, parámetros, reglas de codificación, cuestiones de seguridad, especificación y persona de contacto. La burocracia tenía una ventaja improbable: podía dejar una pista verificable de quién dijo qué acerca de un nombre.

Algunos objetos se intercambiaban sin que existiera una especificación pública completa de sus bytes. El RFC admitía identificarlos por el paquete de software y la versión que los producía. Ese dato situaba el formato con más precisión que un nombre ornamental. Para abrirlo, el destinatario seguía necesitando una implementación que entendiera esa versión. Una entrada compartida ayuda a escoger el cajón; leer su contenido es trabajo del programa.

El procedimiento distinguía tamaños de decisión. Una nueva categoría principal requería un RFC o un borrador apto para serlo y paso por el proceso de estándares. Un subtipo nuevo seguía la vía administrativa. Y si el correo deseaba recomendar solo formatos muy difundidos, podía hacerlo mediante una declaración de aplicabilidad para su entorno. El catálogo común quedaba abierto; el menú de cada aplicación seguía siendo suyo.

RFC 1590 demuestra que una regla de registro puede ser pequeña y estratégica a la vez. No hace falta que el registrador construya cada lector de imágenes o sonidos. Sí hace falta que dos lectores que reciban el mismo objeto puedan empezar por el mismo nombre. La espera de dos semanas compraba una oportunidad pública para detectar una mala elección antes de que la red la convirtiera en costumbre.