Кратко

  • RFC 1926 отображает все шестнадцать полубайтов в буквы, добавляет стартовый символ, передаёт буквы азбукой Морзе и предлагает семь частот для акустических сетей.
  • Единственная фраза о приёме предлагает обратить процесс, но обратная таблица не определяет конец кадра, временные допуски, повреждение, повторную синхронизацию и восстановление.
  • Минимальная спецификация остаётся минимальной не за счёт догадок: немногочисленные решения, влияющие на обе стороны, должны быть общими и проверяемыми.

Полная таблица с неполным входом

Шестнадцать строк отображения создают ощущение замкнутости. Любой полубайт получает букву, а любая буква из выбранного набора возвращается в четыре бита. Однако приёмник не получает буквы как готовые элементы массива. Он получает звук во времени.

В RFC 1926 путь передатчика выстроен последовательно. IP-дейтаграмму делят на четырёхбитные фрагменты в «network beep order». Перед результатом ставят b как сигнал начала кадра. Затем буквы передают обычной азбукой Морзе, включая и выключая постоянный тон.

Частота тона названа «Acoustical Signature» отправителя — ещё одним AS number. Семь значений от 440 до 784 Гц позволяют различать несколько «Local Acoustical Network», а для обычной работы предполагается 440 Гц. Это остроумная и почти законченная модель отправителя.

Приём описан иначе: приведённый процесс просто выполняется в обратном направлении. Но до обратного поиска по таблице нужно отделить точки и тире, символы и целую дейтаграмму. После стартовой b тишина может быть частью ритма Морзе, концом кадра, пропаданием сигнала или остановкой передатчика. Текст не задаёт конечный маркер, длину либо эквивалентный таймер. Разные разумные приёмники могут закрыть один и тот же поток в разные моменты.

Первоапрельская форма не заменяет статус

Документ датирован 1 апреля 1996 года, имеет категорию Informational и прямо говорит, что не задаёт интернет-стандарт какого-либо вида. Нынешняя карточка RFC Editor относит его к Independent Stream. Это современная каталогизация; из неё нельзя без отдельного источника выводить полное тождество процедур 1996 года сегодняшней модели потоков.

RFC 8700, позднейшая история серии, называет RFC к первому апреля особой частью Independent Stream: это юмористические тексты без формального процесса технического рассмотрения и утверждения. Расшифровки ATM, LAN и AS рассчитаны именно на такое чтение.

Архивный номер поэтому доказывает публикацию, а не реализацию. В отобранных источниках нет отчёта о независимо созданной паре, испытаниях в шумном помещении или рабочих измерениях RFC 1926. Но отсутствие такого отчёта в наборе не доказывает, что никто и никогда не собирал демонстрацию. Достоверная граница уже: сам документ не определяет все общие решения приёмника.

Малый протокол может честно назвать свои пределы

В RFC 1055 SLIP намеренно сводится к обрамлению IP-пакетов на последовательной линии. Адресации, идентификации типа, исправления ошибок и сжатия нет. И всё же END завершает пакет; END и ESC внутри данных экранируются; начальный END сбрасывает мусор от линейного шума; приведены алгоритмы отправки и приёма, а также практическая максимальная длина.

Минимальность здесь означает понятную границу ответственности, а не скрытый выбор.

RFC 1662 показывает более строгую границу для PPP с HDLC-подобным кадрированием. Флаг отмечает начало или конец, экранирование и вставка битов обеспечивают прозрачность, FCS обнаруживает повреждение, а недопустимые кадры и межкадровое заполнение имеют определённую обработку. Акустическая схема может выбрать другие механизмы; ей всё равно придётся ответить на разные вопросы, которые эти механизмы разделяют.

Наконец, RFC 1577 описывает настоящий Asynchronous Transfer Mode, который обыгран в названии. Для Classical IP и ARP поверх AAL5 он задаёт контекст виртуальных соединений, стандартную инкапсуляцию LLC/SNAP, IP MTU в 9180 октетов, разрешение адресов и признак окончания PDU в последней ячейке. Повторную передачу он явно оставляет верхним уровням. Передача обязанности другому уровню является спецификацией, если это записано.

Шесть ступеней, которые нельзя перепрыгнуть номером RFC

Первая ступень — представление полубайта буквой. Вторая — модуляция буквы звуком. Третья — кадрирование, благодаря которому приёмник выделяет одну дейтаграмму. Четвёртая — целостность и восстановление после обрыва, повреждения, потери или повтора. Пятая — совместимость независимо написанных реализаций на нормальных и испорченных векторах. Шестая — эксплуатация с измеренными скоростью, задержкой, потерями, дальностью, шумом и совместным использованием среды.

RFC 1926 явно занимает первые две ступени и даёт стартовую подсказку для третьей. Он не устанавливает длительность элементов Морзе, допуски, повторную синхронизацию, размер кадра, коллизии и недопустимые последовательности. Семь частот различают возможные каналы, но не разрешают спор двух отправителей на одной частоте. Предостережение для людного места указывает на поверхность риска, не создавая механизма.

Позднейшая идея Running-Code Primacy требует не смешивать публикацию с реализацией, проверкой, развёртыванием и использованием. Minimum Initial Specification уточняет, что минимальная спецификация строга в немногочисленных общих правилах, от которых зависит совместимость. Reality Layers отделяет символическую долговечность документа и каламбуров от исполнимого факта: сигнал был выделен, проверен и передан IP.

Эти рамки появились позже и не свидетельствуют о намерениях автора. Они помогают сформулировать аккуратный итог: источники не показывают провал RFC 1926 в эксплуатации; текст останавливается до определения испытания, которое могло бы подтвердить успех.