Resumen

  • RFC 1926 asigna letras a los dieciséis valores de cuatro bits, añade un carácter de inicio, usa Morse sobre un tono estable y propone siete frecuencias de red.
  • El texto no define un cierre de trama ni las reglas con las que el receptor separaría pausas, pérdida de señal, corrupción y final de datagrama.
  • La diferencia entre una representación reversible y un enlace interoperable se demuestra en el receptor, con estados, límites de error, implementaciones independientes y pruebas bajo deterioro.

Una inversión que no sabe cuándo detenerse

En el lado emisor, la receta parece redonda. RFC 1926 divide el datagrama IP en grupos de cuatro bits, asigna una letra a cada uno y antepone b como señal de comienzo. Después transmite la cadena en código Morse, encendiendo y apagando un tono. La frecuencia elegida funciona como “Acoustical Signature”; siete notas, entre 440 y 784 Hz, permitirían que convivieran varias “Local Acoustical Networks”.

El lado receptor ocupa una sola frase: se realiza el proceso anterior al revés.

Eso resuelve una operación concreta. Si el receptor ya posee una lista correcta y completa de letras, el cuadro permite recuperar los nibbles. Pero el aire no entrega listas. Entrega energía durante ciertos intervalos, silencio durante otros y ruido entre ambos. El receptor tiene que decidir dónde comienza y acaba cada signo Morse, dónde acaba un carácter y, sobre todo, dónde termina el paquete.

Solo se declara el inicio. Después de oír b, una pausa puede ser sintaxis normal, final de trama, interferencia o abandono del emisor. Sin longitud, marcador final o regla temporal equivalente, dos implementaciones razonables pueden esperar tiempos diferentes y producir datagramas distintos. “Hacerlo al revés” presupone justamente el resultado que debía obtener.

El archivo no promete un enlace

La fecha —1 de abril de 1996— y el lenguaje son deliberados. El documento es Informational y dice expresamente que no especifica ningún estándar de Internet. La ficha contemporánea del RFC Editor lo sitúa en el Independent Stream. Esa clasificación actual no debe convertirse en una descripción retroactiva y completa del procedimiento institucional de 1996.

La historia oficial de la serie aporta el contexto que sí está documentado. RFC 8700 trata los RFC del primero de abril como una práctica especial del Independent Stream: piezas humorísticas sin proceso formal de revisión y aprobación técnica. El número RFC preserva el texto y su procedencia; no certifica un despliegue.

Tampoco conviene saltar al extremo contrario. Las fuentes congeladas no muestran una implementación independiente ni resultados de operación, pero su silencio no prueba que nadie hiciera jamás una demostración. La afirmación sostenible es que RFC 1926, por sí solo, no fija todo lo que dos receptores deben decidir de la misma manera.

Lo mínimo puede ser exigente

RFC 1055 ofrece un contraste casi perfecto porque SLIP presume de hacer muy poco. Solo enmarca paquetes IP en una línea serie; no proporciona direccionamiento, identificación de tipo, corrección de errores ni compresión. Aun así, especifica un carácter END, escapa END y ESC dentro de los datos, propone enviar END al principio para limpiar ruido, describe los algoritmos de envío y recepción y recomienda un tamaño máximo práctico.

La lección no es añadir características. Es declarar tanto las reglas comunes como las carencias.

Para un canal más disciplinado, RFC 1662 define el encuadre tipo HDLC de PPP: una bandera reconoce principio o final, el escape o relleno de bits protege la transparencia, una secuencia de control detecta errores, y existen reglas para tramas inválidas y tiempo entre tramas. No hace falta copiar esa arquitectura a un módem acústico. Basta observar que comienzo, cierre, transparencia, integridad y resincronización son preguntas diferentes.

La expansión cómica de ATM también permite comparar con su referente técnico. RFC 1577 describe IP clásico y ARP sobre Asynchronous Transfer Mode y AAL5. Define el contexto de conexiones virtuales, la encapsulación LLC/SNAP predeterminada, un MTU IP de 9180 octetos, resolución de direcciones y una indicación de fin de PDU en la última celda. Además, asigna la retransmisión a capas superiores. Delegar es válido cuando la delegación está escrita.

Del signo al servicio, seis pruebas distintas

Primero está la representación: letra y nibble se corresponden. Luego la modulación: la letra se expresa como tono y silencio. La trama delimita un datagrama. La integridad y recuperación hacen observables el corte, la alteración, la pérdida y el duplicado. La interoperabilidad exige equipos creados por separado y vectores normales y dañados. La operación añade medidas de caudal, latencia, pérdida, distancia y convivencia.

RFC 1926 llega lejos en las dos primeras y ofrece una pista de inicio para la tercera. No establece duración del punto, tolerancias, resincronización, MTU, control de colisión ni tratamiento de secuencias inválidas. Las frecuencias diferencian canales posibles, pero no arbitran dos emisores en la misma nota. La advertencia sobre lugares concurridos reconoce una superficie de riesgo sin resolverla.

Running-Code Primacy permite leer esta escala sin confundir publicación con uso: cada implementación, validación y despliegue aporta una prueba nueva. Minimum Initial Specification evita una mala conclusión: mínimo no significa indeterminado, sino estricto en aquello que debe ser común. Reality Layers ayuda a separar el símbolo duradero —el RFC y sus juegos de palabras— del hecho ejecutable de que un receptor delimite, compruebe y entregue una señal.

Son marcos posteriores, no la intención atribuida al autor. Con la evidencia disponible, RFC 1926 no es un fracaso operativo documentado. Es una especificación que se detiene antes de formular cómo se demostraría el éxito.