Perfil
Analysis
La inteligencia de perfil de Analysis conecta la cobertura de personas, empresas, instituciones y otras entidades para que los lectores puedan comparar los sujetos detrás de los reportajes de BTW.MEDIA. La página ayuda a comparar perfiles públicos, eventos relacionados, paquetes de evidencia, cambios de cargo, huellas operativas, exposición a la gobernanza, vínculos organizativos y relevancia de mercado, manteniendo a la vez los registros de organizaciones y personas diferenciados de la cronología ordinaria de noticias. Los lectores pueden entender el sujeto detrás del titular, la evidencia que respalda ese perfil y las relaciones de infraestructura o de mercado que lo hacen relevante. Pueden ver a quién o qué representa el perfil, qué fuentes públicas lo respaldan, cómo se conecta con empresas, mercados, organismos de gobernanza o eventos, y qué cambios pueden merecer atención continua a medida que el sujeto evoluciona.
Historia de Internet
El corte no fue un solo corte: cómo RFC 897 separó el cambio de nombre de la resolución DNS
Un host podía conservar durante un tiempo su nombre antiguo como alias. Eso ayudaba a encontrarlo, pero no reparaba el `Cc` guardado en una máquina remota ni una lista de correo mantenida por otra organización. RFC 897 entendió que cambiar un nombre no era una operación local…
Historia de Internet
Las LAN que el host no debía ver: RFC 925 y el coste de ocultar una topología
Un sitio de la Internet temprana podía hacer visible cada cable a la red exterior o conseguir que sus hosts vieran varias LAN como una sola red local. RFC 925 optó por esa segunda ilusión: dejó intacto el ARP del host y trasladó al intermediario el descubrimiento, la memoria y…
Historia de Internet
El portador no era la conexión: cómo RFC 892 separó el estado de transporte del camino de red
Una desconexión de red podía significar dos cosas opuestas. En la clase 0 terminaba también la conexión de transporte. En una clase con recuperación podía iniciar la reasignación a otro portador y una resincronización. RFC 892 convirtió esa diferencia en reglas de protocolo, no…
Historia de Internet
La ruta más rápida llevaba la hora, pero no elegía el reloj maestro: la doble tarea de RFC 891
RFC 891 puso demora, ruta y desfase de reloj en la misma fila de una tabla local. No era una confusión accidental, sino una economía para redes pequeñas. Aun así, mantuvo una frontera esencial: la medición elegía por dónde llegaba la hora; la configuración decidía de quién…
Historia de Internet
La trama era más larga que el datagrama: cómo RFC 894 dejó el relleno de Ethernet fuera de IP
En 2003, el peligro no estaba dentro del datagrama. Varios controladores habían rellenado tramas Ethernet cortas con restos de un búfer anterior. IP terminaba exactamente donde decía Total Length, pero después viajaban bytes capaces de revelar memoria. La vieja norma de RFC 894…
Historia de Internet
Preguntar a todos no era confirmar a nadie: cómo RFC 887 ordenó las pruebas de descubrimiento
RFC 887 diseñó un “no” que solo podía obtenerse al preguntar a una máquina concreta. En la consulta por difusión hablaban los proveedores; en la verificación dirigida también debía contestar quien no ofrecía nada. La audiencia cambiaba el significado de la respuesta.
Historia de Internet
La lista decía «oficial», no «implementado»: cómo RFC 880 separó el estatus del código en ejecución
TFTP figuraba como electivo y, al mismo tiempo, como usado en varias redes locales. La lista no intentó resolver esa diferencia borrando una de las dos frases. RFC 880 trató la libertad de adoptar y el hecho de haber adoptado como afirmaciones distintas.
Historia de Internet
La puerta trasera no era una ruta: cómo RFC 831 llegaba a un SATNET dividido
Un solo equipo estadounidense podía hablar con cada destino SATNET. No era una cuota comercial ni una previsión de capacidad: era la consecuencia visible de una memoria de retorno que había perdido información. RFC 831 aceptaba esa estrechez para mantener el acceso de…
Historia de Internet
La pasarela llevó los bytes, pero no inventó el significado: cómo RFC 875 cuestionó la traducción de protocolos
Una copia de seguridad idéntica no podía salvar una conversación que sólo existía en la memoria de la pasarela activa. RFC 875 llegó a esa fragilidad antes de hablar de redundancia: primero mostró que traducir direcciones, confirmaciones, flujo y señales excepcionales obligaba al…
Historia de Internet
El archivo maestro podía estar al día y la red no: cómo RFC 849 repartió el trabajo entre envío y consulta
Un registro actualizado no reescribe por sí solo la copia de una máquina apagada. En mayo de 1983, Mark Crispin convirtió esa distancia en un problema de ingeniería: identificar la versión, entregar los bytes, comprobarlos, instalarlos y recuperar lo que el primer aviso no…
Historia de Internet
El censo que preguntó a los puertos: cómo RFC 832 separó declaración y servicio
El Internet de diciembre de 1982 tenía un padrón de máquinas y una migración urgente, pero no tenía derecho a confundir ambas cosas con funcionamiento. David Smallberg convirtió las entradas del NIC en hipótesis: llamó a los puertos de Telnet, FTP y SMTP, distinguió las maneras…
Historia de Internet
La tecla atravesó dos sesiones: cómo RFC 818 convirtió al cliente Telnet en servicio
El operador pulsaba una tecla y veía un solo terminal. La tecla, sin embargo, terminaba una conexión Telnet, cruzaba un pseudo-terminal dentro de un concentrador y entraba en otra conexión iniciada por un segundo programa. RFC 818 hizo accesible ese montaje en el puerto 107. Su…
Historia de Internet
El servicio de nombres casi fue un negociador: cómo RFC 830 separó dominios y capacidades
Una consulta de RFC 830 podía recibir dos respuestas en momentos distintos. La primera conducía al punto de servicio del dominio de destino. La segunda decía si allí existía el transporte y la aplicación solicitados, o proponía una alternativa. Entre ambas quedaba una frontera…
Historia de Internet
El número no lo convertía en estándar: cómo RFC 825 hizo visible la intención del documento
Un informe de política cita una RFC y, al copiarla, pierde una sola palabra: *Informational*. El enlace sigue funcionando y el número sigue siendo exacto, pero la afirmación ha cambiado. Lo que era una publicación para informar empieza a parecer una recomendación técnica. RFC 825…
Historia de Internet
La capa no era el módulo: cómo RFC 817 atravesó la pila
En Multics, sumar el checksum de un segmento TCP de 576 bytes llegó a consumir unos seis milisegundos. No era porque TCP exigiera seis milisegundos, sino porque bytes de ocho bits caían incómodamente dentro de palabras de 36. Una reescritura muy localizada redujo el tiempo a…
Historia de Internet
El mensaje de error era un consejo, no un veredicto: cómo RFC 816 repartió las decisiones de fallo
El fallo más difícil de denunciar era el de la primera pasarela: al morir, también perdía la capacidad de explicar por qué desaparecían los paquetes. RFC 816 convirtió esa paradoja en una arquitectura de responsabilidades, desde la selección de ruta hasta el acuse final de la…
Historia de Internet
El segmento perdido no detenía al siguiente: cómo RDP separó fiabilidad y orden
Una imagen de memoria puede llegar por piezas. Si falta una, la imagen está incompleta; eso no convierte en inútiles las piezas posteriores que sí llegaron y que saben dónde deben colocarse. El Reliable Data Protocol nació de esa diferencia. Aseguraba que el hueco acabaría…
Historia de Internet
El nombre no era la dirección: cómo RFC 814 separó la identidad de la ruta
Un ordenador personal con una sola sesión Telnet no necesitaba conocer todos los destinos de Internet; quizá le bastaba una asociación de ruta. Un sistema compartido podía necesitar cien. RFC 814 partió de esa diferencia para defender algo mayor: el estado local debía crecer con…
Historia de Internet
El acuse que terminaba en el enlace: cómo PPP acotó la fiabilidad
Un acuse de recibo puede cerrar una duda y abrir otras. RFC 1663 permitió a dos vecinos PPP recuperar tramas perdidas con números de secuencia, ventanas y retransmisiones. Pero el significado del acuse terminaba allí: no acreditaba al interlocutor, no garantizaba una ruta y no…
Historia de Internet
La jerarquía era en realidad un grafo: cómo Gopher puso el siguiente servidor en cada línea de menú
Gopher parecía un archivador ordenado, pero cada selección podía abandonar la máquina que mostraba el menú. La línea elegida llevaba dos historias a la vez: una etiqueta amable para la persona y una instrucción precisa para el programa, compuesta por tipo, selector opaco, host y…