Что такое rfc, в каком формате публикуются файлы rfc

Обновлено: 30.06.2024

В этом документе обсуждаются варианты и требования к отображению RFC в формате PDF из серии RFC, как указано в RFC 6949. Также обсуждается использование PDF для Интернет-черновиков, а также доступные или необходимые программные средства для создания PDF-файлов и работы с ними. .

Статус этой заметки

Этот документ не является спецификацией для отслеживания стандартов Интернета; он опубликован в информационных целях.

Этот документ является продуктом Совета по архитектуре Интернета (IAB) и содержит информацию, которую IAB счел ценной для постоянного хранения. Он представляет собой консенсус Совета по архитектуре Интернета (IAB). Документы, одобренные для публикации IAB, не являются кандидатами на любой уровень интернет-стандарта; см. раздел 2 RFC 7841.

Уведомление об авторских правах

Содержание

1. Введение

Серия RFC развивается, как указано в [RFC6949]. Будущие документы будут использовать канонический формат XML с визуализацией в различных форматах, включая PDF.

Поскольку PDF имеет широкий спектр возможностей и альтернатив, не все PDF-файлы «одинаковы». Например, визуально похожие документы могут состоять из отсканированных или растровых изображений или включать параметры макета текста, гиперссылки, встроенные шрифты и цифровые подписи. (Историю PDF см. в [APP-PDF].)

В этом документе объясняются некоторые из соответствующих параметров и даются рекомендации как для RFC Series, так и для Internet-Drafts.

Формат PDF и инструменты для работы с ним не так хорошо известны, как другие форматы RFC, по крайней мере, в сообществе IETF. В этом документе обсуждаются некоторые процессы создания и использования PDF-файлов с использованием как открытых, так и коммерческих продуктов.

Ожидается, что детали, описанные в этом документе, изменятся в зависимости от опыта, полученного при внедрении новых наборов инструментов публикации. Пересмотренные документы будут опубликованы с учетом этих изменений по мере завершения набора инструментов. Другие разработчики не должны ожидать, что эти изменения останутся обратно совместимыми с деталями, описанными в этом документе.

2. Выбор версий и стандартов PDF

PDF [PDF] претерпел несколько изменений, прежде всего для добавления функций. Функции PDF, как правило, добавляются таким образом, чтобы более старые программы просмотра "не терпели неудачу", но даже в этом случае, чем старше версия PDF, тем больше устаревших программ просмотра будут поддерживать эту версию, но будет включено меньше функций.

Поскольку в формате PDF появился широкий набор возможностей, к файлам PDF применимы дополнительные стандарты. Эти стандарты устанавливают основные правила, важные для конкретных приложений. Например, PDF/X был специально разработан для обмена цифровыми данными допечатной подготовки с особым вниманием к управлению цветом и инструкциям по печати. Стандарт PDF/E был разработан для инженерных документов с динамическими рабочими процессами (когда документ продолжает редактироваться после публикации) и допускает интерактивные мультимедиа (включая анимацию и 3D).

Эти стандарты эффективно и полезно использовать для захвата PDF-файлов в соответствии с требованиями RFC, и они сделают PDF-файлы полезными в рабочих процессах, которые их ожидают.

Используйте PDF 1.7; несмотря на то, что он относительно недавно, он хорошо поддерживается широко доступными зрителями.

Для RFC требуется PDF/A-3 с уровнем соответствия "U". Это обеспечивает архивируемость и долговременную стабильность файлов PDF 1.7, обязательное сопоставление Unicode (разделы 14.8.2.4.2 («Сопоставление Unicode в PDF с тегами») и 9.10.2 («Сопоставление кодов символов со значениями Unicode») [PDF ]), а также многие необходимые функции.

Используйте PDF/A-3 для встраивания дополнительных данных (включая исходный XML-файл) в RFC и интернет-черновики.

Используйте PDF/UA для удобства пользователей.

3. Варианты и требования для PDF RFC

В этом разделе представлены параметры и требования к файлам PDF, создаваемым RFC Editor для RFC. Есть два подраздела: Раздел 3.1 охватывает «видимые» требования, связанные с тем, как PDF-файл обычно выглядит при просмотре с помощью программы просмотра PDF-файлов; В разделе 3.2 рассматриваются «невидимые» параметры и требования, которые в первую очередь влияют на возможность обработки PDF-файлов другими способами, но обычно не контролируют внешний вид документа. (Конечно, пользовательский интерфейс средства просмотра может отображать возможности обработки, например показывать, подписан ли документ цифровой подписью.)

Во многих случаях на выбор требований к PDF сильно влияют возможности доступных инструментов для создания PDF-файлов. Большинство обсуждений инструментов можно найти в Приложении C.

3.1. «Видимые» требования

PDF поддерживает расширенный видимый макет страниц фиксированного размера.

3.1.1. Общие требования к видимым элементам

Чтобы RFC выглядели единообразно и имели хороший стиль, PDF-файлы, созданные редактором RFC, должны иметь четкий, последовательный, узнаваемый и легко читаемый стиль. Они должны хорошо печатать на самых разных принтерах и хорошо выглядеть на дисплеях с разным разрешением.

3.1.2. Размер страницы и поля

Файлы PDF создаются для определенного размера страницы и полей. Обычно используются два размера бумаги: «US Letter» (8,5x11 дюймов, 216x279 мм, широко используется в Северной Америке) и «A4» (210x297 мм, 8,27x11,7 дюймов, стандарт для остального мира). . Обычно программное обеспечение для печати PDF используется в режиме «уменьшения размера», когда печать настраивается в соответствии с размерами бумаги в принтере. Есть некоторые разногласия, но аргумент, что A4 является международным стандартом, убедителен. Однако, если поля и расположение заголовка выбраны правильно, документ можно распечатать без какого-либо масштабирования.

3.1.3. Верхние и нижние колонтитулы

Верхние и нижние колонтитулы являются частью макета страницы. Есть множество вариантов. Обратите внимание, что верхние и нижние колонтитулы страниц в формате PDF могут быть набраны таким образом, чтобы поместился весь (более длинный) заголовок.

3.1.4. Нумерация абзацев

Одной из общих черт выходных форматов Internet-Draft является наличие необязательных видимых номеров абзацев для облегчения обсуждения. В PDF и, следовательно, в печатной версии номера абзацев можно сделать ненавязчивыми и даже на полях.

3.1.5. Макет постраничного контента

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

Приложение B описывает процесс создания документа с разбивкой на страницы из бегущего текста таким образом, чтобы связанный материал находился вместе на одной странице, а артефакты нумерации страниц не мешали легкому чтению документа.

Двигатели макетов отличаются качеством алгоритмов, используемых для автоматизации этих процессов. В некоторых случаях автоматизированным процессам требуется ручная помощь, чтобы гарантировать, например, что текстовая строка, предназначенная для использования в качестве заголовка, «сохраняется» вместе с текстом, для которого она является заголовком.

Верхние и нижние колонтитулы должны быть напечатаны на каждой странице. Информация должна включать номер RFC или название Интернет-проекта, номер страницы, категорию (например, информационная), сокращенную версию имен авторов, дату RFC или Интернет-проекта и краткую форму название документа.

Выберите механизм компоновки, чтобы

ручное вмешательство сведено к минимуму

обработка вдов и сирот осуществляется автоматически

связывание заголовков и заголовков выполняется автоматически

3.1.6. Выбор шрифта

Файл PDF может ссылаться на шрифт по имени или может использовать встроенный шрифт. Если шрифт не встроен, программа просмотра PDF попытается найти локально установленный шрифт с таким же именем. Если он не может найти точное совпадение, он найдет «близкое совпадение». Если близкое совпадение недоступно, оно вернется к чему-то, что зависит от реализации и обычно нежелательно.

Кроме того, стандарты PDF/A требуют встраивания шрифтов. Вместо того, чтобы использовать дополнительное программное обеспечение для встраивания шрифтов, программное обеспечение, создающее файлы PDF, должно создавать файлы, соответствующие формату PDF/A, что гарантирует, что все глифы с самого начала включают сопоставления Unicode и встроенные шрифты.

Если HTML-версия документа визуально имитируется, выбранные шрифты должны иметь компоненты как переменной, так и постоянной ширины, а также полужирный и курсивный шрифты.

Наборы шрифтов, используемые Internet-Drafts и RFC, могут не совпадать.

Немногие шрифты содержат глифы для всего набора символов Unicode; для этой цели инструменту генерации PDF может понадобиться набор шрифтов и способ их выбора. Редактор RFC определяет, где в RFC могут использоваться символы Unicode [RFC7997].

Начертания шрифтов обычно лицензируются, и во многих случаях за использование инструментов для создания PDF-файлов взимается плата; однако плата за отображение или печать встроенных шрифтов обычно не взимается.

Для согласованного просмотра все шрифты должны быть встроены. Используемые шрифты должны быть доступны для использования сообществом IETF. Некоторое обсуждение доступных шрифтов можно найти в Приложении C.4.

Выбор шрифтов с засечками, без засечек, моноширинный шрифт и т. д. должен соответствовать рекомендациям по отображению HTML и CSS ("CSS" относится к каскадным таблицам стилей) [RFC7992] и [RFC7993].< /li>

Диапазон символов Unicode, разрешенный в исходном XML для Internet-Drafts и RFC, может быть ограничен доступностью встраиваемых шрифтов с соответствующими глифами [RFC7997].

3.1.7. Переносы и разрывы строк

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

3.1.8. Гиперссылки

PDF поддерживает гиперссылки на разделы одного и того же документа, а также на разделы других документов.

Преобразование в PDF может создать:

гиперссылки внутри документа

гиперссылки на другие RFC и интернет-черновики

гиперссылки на внешние ресурсы

гиперссылки в оглавлении

гиперссылки в индексе

Все гиперссылки, доступные в HTML-версии RFC, также должны быть видны и активны в созданном PDF-файле. Сюда входят как внутренние гиперссылки, так и гиперссылки на внешние ресурсы.

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

Как указано в разделе 4.8.6.2 («Ссылки на RFC») [RFC7322], гиперссылки на RFC из раздела ссылок должны указывать на «информационную» страницу RFC (например, ), которая затем ссылается на различные доступные форматы. .

Гиперссылки на Интернет-черновики из раздела ссылок должны указывать на страницу входа в Datatracker для черновика, которая затем ссылается на различные доступные форматы.

3.1.9. Сходство с другими результатами

Есть некоторые преимущества в том, чтобы PDF-файлы выглядели как текст или HTML-рендеринг того же документа. Тем не менее, есть несколько вариантов. PDF

может выглядеть как текстовая версия документа или

может выглядеть как текстовая версия документа, но с изображениями, отображаемыми как изображения, а не с использованием их художественного эквивалента ASCII, или

может выглядеть как HTML-версия.

Таким образом, применимо большинство вариантов, используемых для визуализации в соответствии с [RFC7992] и [RFC7993]. См. эти документы для получения подробной информации об отображении определенных элементов XML. Некоторые примечания:

3.2. «Невидимые» параметры и требования

PDF предлагает ряд функций, повышающих полезность файлов PDF в различных рабочих процессах за счет дополнительных усилий в процессе преобразования xml2rfc; компромиссы могут быть разными для RFC Editor и для Internet-Drafts.

3.2.1. Представление внутреннего текста

Содержимое файла PDF может быть представлено разными способами. Файл PDF может быть сгенерирован:

как изображение визуального представления, например изображение слова "IETF" в формате JPEG. То есть может вообще не быть внутреннего представления букв, слов или абзацев.

размещение отдельных символов на странице, например: "поставьте здесь букву "F", затем "поставьте перед ней букву T", затем "поставьте перед ней букву E", затем "поставьте букву «Я» до этого», чтобы отобразить слово «IETF». То есть может вообще не быть внутреннего представления слов или абзацев.

размещение слов на странице, например совмещение символов слова "IETF". То есть может вообще не быть внутреннего представления абзацев.

обеспечение того, чтобы порядок воспроизведения текста в потоке контента соответствовал логическому порядку чтения. То есть такое предложение, как «Инженерная группа Интернета (IETF) поддерживает Интернет». будут храниться вместе как предложение, а несколько предложений в абзаце будут храниться вместе.

Все они в конечном итоге дают одинаковое визуальное представление результата. Однако у каждого уровня есть компромиссы для вспомогательных целей, таких как поиск или индексирование, комментирование и аннотация, а также доступность (преобразование текста в речь). Сохранение порядка воспроизведения текста в потоке контента в правильном порядке поддерживает все эти вспомогательные функции.

Кроме того, функция «карты ролей» PDF (раздел 14.7.3 («Типы структур») [PDF]) позволяет отображать логические теги, найденные в исходном XML, в теги в PDF.

Текст в потоках контента должен, насколько это возможно, следовать логическому порядку XML-документа (порядку тегов). Это обеспечит оптимальное повторное использование программным обеспечением, которое не понимает Tagged PDF. (Это требуется для PDF/UA.)

Возможно, можно использовать аннотацию «карта ролей», чтобы захватить достаточное количество исходной структуры xml2rfc до такой степени, что можно будет полностью реконструировать исходную структуру XML.Однако нет веских оснований делать это вместо встраивания исходного XML, как описано в Разделе 3.2.7.

3.2.2. Поддержка Юникода

Сам PDF не требует использования Unicode. Текст представлен в виде последовательности глифов, которые затем можно сопоставить с Unicode.

Созданные PDF-файлы должны иметь полный текст, как в исходном XML.

Может произойти нормализация Unicode.

Текст в SVG для изображений SVG также должен иметь сопоставление Unicode.

Альтернативный текст для изображений также должен поддерживать Юникод.

3.2.3. Обработка изображений (обложка)

XML позволяет использовать для иллюстраций как ASCII, так и SVG.

Если для изображения доступны как обложка ASCII, так и SVG, обложка SVG должна быть предпочтительнее, чем обложка ASCII.

Обложка ASCII должна отображаться с использованием моноширинного шрифта.

3.2.4. Текстовое описание изображений (Alt-Text)

Рекомендации по доступности PDF рекомендуют, чтобы изображения, формулы и другие нетекстовые элементы предоставляли текстовые альтернативы, используя тег "/Alt" в PDF для предоставления удобочитаемого текста, который может быть озвучен с помощью преобразования текста в речь. технология.

3.2.5. Поддержка метаданных

Метаданные кодируют информацию об авторах документа, серии документов, дате создания и т. д. Наличие этих метаданных в файле PDF позволяет использовать их поисковыми системами, программами просмотра и другими инструментами повторного использования. PDF поддерживает встроенные метаданные различными способами, включая использование расширяемой платформы метаданных (XMP) [XMP]. Редактор RFC поддерживает метаданные о RFC на своей информационной странице.

3.2.6. Поддержка структуры документа

PDF поддерживает функцию "контур", когда разделы документа помечаются; его можно использовать в дополнение к оглавлению в качестве вспомогательного средства навигации.

Структура разделов RFC может быть отображена в элементы PDF для структуры документа. Это позволит использовать функцию закладок программ чтения PDF для быстрого доступа к разделам документа.

3.2.7. Встроенные файлы

PDF может включать другие файлы; файлы могут быть помечены как типом носителя, так и ролью, ключом AFRelationship [PDFA3]. Таким образом, файл PDF также действует как контейнер.

Встроенный контент может быть сжат.

Многие программы просмотра PDF поддерживают возможность просмотра и извлечения встроенных файлов, хотя эта возможность не является универсальной.

Встраивание содержимого в файл PDF позволяет PDF действовать как полный пакет, который можно преобразовывать, архивировать и ставить цифровую подпись. (Некоторые примеры кода, иллюстрирующие, как элементы могут быть присоединены к файлу PDF и впоследствии извлечены, можно найти по адресу .) Полезные возможности:

Встроить исходный входной XML-файл в PDF-файл. Если исходный SVG и изображения для иллюстраций также встроены, это сделает файл PDF полностью самостоятельным.

Встраивайте непосредственно извлекаемые компоненты, полезные для независимой обработки, включая ABNF, MIB и исходный код для эталонных реализаций. Эта возможность может поддерживаться с помощью других механизмов из исходных файлов XML, но также может поддерживаться в PDF-файле.

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

Внедрение исходного кода XML и всех иллюстраций для RFC в качестве стандартной функции для вывода xml2rfc в формате PDF.

Если возможно, сделайте это стандартной функцией и для Internet-Drafts.

Именованные записи должны быть встроены.

Растровые изображения (источники SVG, JPEG, PNG и т. д.) должны быть встроены.

3.3. Цифровые подписи

Редактор RFC и сотрудники иногда вызываются для предоставления доказательств того, что конкретный RFC является «оригинальным» и не подвергался изменениям; цифровые подписи могут обеспечить такую проверку. Поскольку подписи применяются и к встроенному содержимому, встраивание исходного XML-файла позволит подписать исходный XML-код, который также использовался для создания PDF-файла.

PDF поддерживает цифровые подписи, начиная с PDF 1.2, и существует несколько методов и параметров для подписи PDF-файлов. Метод, выбранный для подписания Internet-Drafts и RFC, будет определяться отдельной политикой.

Редактор RFC больше не является одним человеком; это небольшая группа людей. ООО «Администрация IETF» (IETF LLC) заключает контракт на выполнение функций редактора RFC с компанией Association Management Solutions, LLC (AMS). В течение 2009 года местом работы редактора RFC было Сетевое подразделение Института информационных наук Университета Южной Калифорнии (ISI) в Марина-дель-Рей, Калифорния. ISI сыграла ключевую роль в развитии Интернета, и Джон Постел много лет был директором сетевого подразделения ISI.Исторический отчет о серии RFC см. в статьях «30 лет RFC», «40 лет RFC» и «50 лет RFC».

Каждый RFC относился к «Сетевой рабочей группе» (до публикации RFC 5741). Что это за рабочая группа?

Эта метка в заголовке RFC является исторической по форме и символической по содержанию. Исторически «Сетевая рабочая группа» означала группу исследователей, которые разрабатывали протоколы коммутации пакетов для ARPAnet, начиная с 1969 года. Этот ярлык сохранился в RFC как напоминание о долгой и важной технической истории, которая записана в серии RFC, и как напоминание о том, что сегодняшние технические решения, мудрые или нет, могут быть с нами долгие годы. Сегодня «сетевую рабочую группу» следует понимать как группу пользователей, поставщиков и исследователей, которые работают над улучшением и расширением Интернета.

Все ли RFC являются стандартными документами для Интернета?

Одним словом «НЕТ!». Многие RFC имеют информационный или экспериментальный статус и не представляют собой какой-либо стандарт. Они содержат информацию, которую может быть полезно или важно сохранить в этой серии архивных документов. Это важно понимать, потому что недобросовестные маркетологи и небрежная отраслевая пресса иногда ложно предполагают, что каждый RFC представляет собой стандарт или что все стандарты имеют одинаковый вес. Отношения между техническими спецификациями Интернета часто бывают сложными.

Как узнать, где в Standards Track находится RFC?

Может ли измениться статус RFC после публикации?

Да, статус RFC может измениться; эта информация доступна в нескольких местах, включая информационную страницу RFC и результаты поиска RFC. Например, RFC можно переместить из предлагаемого стандарта в интернет-стандарт (как описано в RFC 6410) или из информационного в исторический. Список всех RFC, статус которых изменился, см. в списке изменений статуса.

Как исправить ошибку в опубликованном RFC?

Вы не можете! После публикации RFC его нельзя изменить. RFC составляют архивную серию. Если ошибка представляет собой изменение содержимого, может быть написан пересмотренный RFC, который устаревает по ошибке. Как для технических, так и для редакционных ошибок редактор RFC предоставляет список исправлений для опубликованных RFC. Используйте страницу RFC Errata для поиска исправлений по номеру RFC или просмотра полного списка. Кроме того, результаты поиска на странице поиска RFC включают гиперссылки на любые соответствующие записи об ошибках. Чтобы сообщить об ошибке в RFC, используйте форму, доступную на странице RFC Errata (подробности см. в разделе Как сообщить об ошибках).

Для RFC, в которых проверены технические ошибки, доступны файлы с ошибками, показанными внутри (когда это возможно). Они указаны как «HTML со встроенными исправлениями» в результатах поиска RFC и на информационных страницах. Например:
RFC 5234.

Все RFC могут свободно воспроизводиться и переводиться (без изменений). С момента публикации RFC 5377 и RFC 5378 в ноябре 2008 г. уведомление об авторских правах и легенды, которые появляются в RFC, определяются положениями IETF Trust Legal Provisions. Дополнительную информацию см. в часто задаваемых вопросах об авторском праве IETF Trust.

Поток документов	Отслеживание стандартов*	Передовой опыт (BCP)	Экспериментальный	Информационный	Исторический
IETF	X	X	X	X	X
IRTF	X	X	X
IAB	X	X	X	X
Независимый	X	X	X

* включая Интернет-стандарт (STD) и предлагаемый стандарт

Поток	Менеджер потоков
IAB
IETF	IESG
Независимые материалы	ISE
IRTF	IRSG

Я не могу получить текст RFC. Почему бы и нет?

Существует список номеров RFC, присвоенных документам, которые фактически никогда не публиковались. Это объясняет случайный разрыв между цифрами. Нынешние процедуры созданы для того, чтобы очень стараться избежать такой ситуации в будущем. В частности, номера RFC никогда не резервируются; скорее, они назначаются в последний момент в процессе редактирования.

Кроме того, некоторые RFC до версии 800 существовали только на бумаге.Редактор RFC имеет проект «RFC Online», чтобы сделать всю серию RFC доступной в Интернете. Однако этот процесс обязательно имел более низкий приоритет, чем редактирование новых RFC. Мы благодарны за помощь волонтерам интернет-сообщества, которые ввели и восстановили текст отсутствующих RFC в Интернете.

Когда я извлекаю RFC, каждая строка заканчивается на «^M». Что дает?

См. «История конца строки» для исторического отчета о проблеме и возможных решениях.

Редактор RFC не публикует репозиторий в печатном виде. На это есть несколько причин. Во-первых, с более чем восемью тысячами RFC размер печатной копии занял бы несколько книжных полок. Во-вторых, учитывая, что большая часть сообщества получает электронные версии этих документов, не хватает рынка, чтобы оправдать расходы на печать. Наконец, репозиторий RFC постоянно расширяется. Любая печатная версия быстро устареет.

После того как мой документ отправлен в IESG на проверку или одобрен IESG для публикации, как я узнаю, что редактор RFC поставил его в очередь?

Сколько времени требуется, чтобы документ стал RFC?

Обычно время публикации составляет 1–2 месяца, но фактические сроки сильно различаются от одного RFC к другому. Публикация может быть отложена по разным причинам, включая одобрение IESG, несоответствия или упущения, обнаруженные при редактировании, или нормативные ссылки на другие документы, которые должны быть опубликованы раньше или одновременно. (Для получения текущей информации о документах, связанных нормативными ссылками, см. страницу кластера.) Авторы также должны знать, что очередь RFC может быть перегружена непосредственно перед собраниями IETF.

Нет, резервирование номера RFC невозможно. Номер RFC, присвоенный данному документу, освобождается, когда документ переходит в состояние AUTH48. Для получения дополнительной информации о том, почему была принята эта политика, см. раздел Я не могу получить текст RFC. Почему бы и нет?

Что я могу сделать, чтобы ускорить процесс публикации RFC?

Внимательно прочитайте все инструкции. Убедитесь, что ваш документ правильно отформатирован. См. процесс публикации RFC и Руководство по стилю RFC.

Я только что обнаружил, что в моем документе есть опечатки, или мой адрес или место работы изменились. Что мне делать?

Если ваш документ находится в очереди редактора RFC, отправьте изменения в редактор RFC в любое время.

Какое руководство по стилю использует редактор RFC?

См. Руководство по стилю RFC. Кроме того, мы обычно ссылаемся на «Чикагское руководство».

Как следует указывать RFC в разделе ссылок?

Ссылки на RFC должны отображаться, как описано в интерактивной части Руководства по стилю редактора RFC; см. «Ссылки на RFC».

Репрезентативные ссылочные теги (например, [RFC2119]) предпочтительнее числовых ссылочных тегов (например, [1]).

Как следует перечислять Internet-Drafts в разделе ссылок?

xml2rfc будет ссылаться на самую последнюю версию I-D при использовании этого формата. Если требуется ссылка на конкретную версию ИД, укажите номер версии как часть URL-адреса.

Смогу ли я просмотреть свой документ, прежде чем он станет RFC?

Один из авторов более недоступен; как нам быть?

Мы рекомендуем один из следующих путей:

Автор может быть удален из списка авторов и перемещен в раздел "Благодарности".
Автор может быть удален из списка авторов и перемещен в раздел "Соавторы".
Менеджер потока может утвердить документ вместо недоступного автора. (См. Заявление IESG о состоянии AUTH48.)

Вариант 3 обычно используется в тех случаях, когда отсутствующий автор внес существенный вклад в документ, поэтому другим авторам неудобно удалять человека из списка авторов.

После того как интернет-проект рабочей группы утверждается для публикации в качестве RFC, как председатели рабочих групп и региональные директора участвуют в процессе публикации?

Председатели рабочих групп и региональные директора получают копии каждого сообщения, отправляемого редактором RFC авторам в ходе процесса публикации, поэтому у них есть возможность внести свой вклад в любое время. В частности, когда в документ вносятся какие-либо изменения, выходящие за рамки редакционных требований, требуется одобрение Регионального директора. Ответ от председателей РГ может быть запрошен по вопросам, которые затрагивают более одного документа их РГ, или для решений о том, нужно ли РГ рассматривать изменения.

Document Shepherd (если не один из председателей WG) также получает копию каждого сообщения от редактора RFC в процессе публикации.

После публикации RFC авторы, а также председатели рабочих групп и региональные директора получают уведомление, если для этого RFC сообщается об ошибках.

Что делать, если я хочу включить в RFC диаграммы, которые нельзя отобразить в ASCII?

Для фона: перед переходом на v3 XML была возможность опубликовать PDF-файл с улучшенными изображениями после публикации текста ASCII. Он будет содержать точный текст RFC с добавленными диаграммами. Этот файл был создан авторами. С 16 сентября 2020 года авторы больше не могут отправлять улучшенные PDF-файлы, поскольку они могут использовать SVG для создания рисунков в RFC.

Обратите внимание, что улучшенные PDF-файлы, опубликованные до этой даты, по-прежнему доступны. Примерами RFC, в которых используется этот параметр, являются RFC 4128, RFC 4137, RFC 4601, RFC 5059, RFC 5317 и RFC 5598. Необязательный PDF-файл указан как «PDF с изображениями».

Как заставить исходный файл написать документ «bis» (документ, который сделает существующий RFC устаревшим)?

Для номеров ниже RFC 8650 исходные файлы (XML или NROFF) доступны по запросу; отправьте письмо редактору RFC.

Это файл перед запуском инструмента подготовки, определенного в RFC 7998. Прежде чем опубликовать исходный файл RFC, мы используем инструмент xml2rfc для выполнения процесса, называемого «подготовкой» XML. При этом заполняются значения по умолчанию, добавляются явные номера разделов и добавляются другие данные (включая любое внешнее содержимое), чтобы упростить согласованную визуализацию XML в других форматах. Хотя подготовленный XML идеально подходит для рендеринга, он далеко не идеален для редактирования, поскольку номера разделов могут меняться по мере добавления или изменения порядка текста, а все значения по умолчанию могут затруднить поиск полезных элементов и атрибутов XML.

Представления от 1 апреля — это единственные будущие RFC, которые не нужно публиковать как интернет-черновики. Эти записи должны быть отправлены непосредственно в редактор RFC. Мы благодарны за получение всех заявок не менее чем за 2 недели до 1 апреля, чтобы у команды редакторов RFC было время просмотреть все документы и подготовить те, которые мы решили опубликовать.

Как работает AUTH48?
См. инструкции по заполнению AUTH48 здесь.

Вы отправили мне URL-адрес моего файла XML, но я не могу просмотреть файл XML в своем браузере. Как мне его получить?

В браузере есть несколько вариантов сохранения XML-файла. Пожалуйста, используйте «просмотреть исходный код страницы» (или аналогичный) и сохраните файл.

где XXXX — номер RFC.

Когда я могу отправить свои изменения?
Если ваш документ находится в AUTH48, отправьте изменения как можно скорее. Это ваш последний шанс внести изменения; как только документ будет опубликован как RFC, мы не будем вносить изменения.

Можно ли изменить расположение разрывов страниц?
В формате v3 нет, обычно мы не можем изменить расположение разрывов страниц (которые появляются только в выходном файле PDF).

где XXXX – присвоенный номер RFC.

Что делать, если один из авторов недоступен?
Это то же самое, что и тема, описанная выше.

Почему менеджер потока должен одобрять изменения?
Мы попросим менеджера потока просмотреть и утвердить любые изменения, выходящие за рамки редакционных по своему характеру, например, добавление нового текста, удаление текста и технические изменения. изменения. См. информацию о менеджерах потоков выше. Редакционные изменения не требуют одобрения менеджера трансляции.

Независимо от того, какую книгу или руководство вы используете для подготовки к экзамену CCNA, вы увидите различные протоколы и процессы, ссылающиеся на RFC. И хотя RFC часто упоминаются, они редко включаются в документацию. Таким образом, возникает логичный вопрос: «Что такое RFC и где их найти?»

В области разработки и проектирования компьютерных сетей запрос комментариев (RFC) – это меморандум, опубликованный Инженерной группой Интернета (IETF), в котором описываются методы, модели поведения, исследования или инновации, применимые к работе в Интернете, а также с системами, подключенными к Интернету.

Через организацию, известную как Internet Society, дизайнеры, инженеры и компьютерщики могут публиковать статьи или выступления в форме RFC либо для рецензирования, либо просто для обмена новыми концепциями, информацией или (иногда) инженерным юмором. . Рецензирование — это важный процесс, при котором ваша работа, исследование или личные идеи подвергаются тщательному анализу другими людьми, которые обычно считаются экспертами в той же области. Затем IETF примет некоторые из предложений, опубликованных в виде RFC, в качестве «интернет-стандартов».

Начало формата и процесса RFC произошло в 1969 году в рамках первоначального проекта ARPANET, который представлял собой обширную экспериментальную сеть, соединяющую хосты и серверы терминалов вместе. Были установлены процедуры для регулирования распределения адресов и создания добровольных стандартов для сети. Авторы первых RFC фактически использовали пишущие машинки для создания своей работы и передавали печатные копии исследователям ARPA.

В отличие от современных RFC, многие ранние RFC представляли собой настоящие запросы на комментарии. RFC оставил вопросы открытыми и был написан в менее формальном стиле. Этот менее формальный стиль теперь типичен для документов Internet Draft, предшествующих шагу перед утверждением в качестве RFC.

Запросы RFC оказались удобным и полезным средством документирования и распространения исследований, проведенных разработчиками Интернета, и в конечном итоге стали официальным документом о дизайнерских решениях, архитектуре и технических стандартах Интернета. Хотя они по-прежнему назывались «Запрос комментариев», по общему мнению, они являются официально зарегистрированными интернет-документами и часто содержат очень подробную техническую информацию.

Теперь рабочие группы IETF выполняют большую часть работы по стандартизации интернет-протоколов, поскольку они проходят этапы предлагаемого стандарта, проекта стандарта и фактического стандарта. Протокол, опубликованный в качестве предлагаемого стандарта, обычно предназначен для того, чтобы стать фактическим стандартом, но не продвигается до проекта стандарта в течение как минимум шести месяцев, чтобы интернет-сообщество имело время рассмотреть и прокомментировать его. Проект стандарта не продвигается до полного стандарта в течение как минимум четырех месяцев после получения опыта эксплуатации и демонстрации функциональной совместимости двух или более независимых реализаций.

Существует множество официальных стандартов интернет-протокола. К счастью, есть полный список официальных стандартов, задокументированных в документах запроса на комментарии, с последней версией в RFC 3300 и актуальным списком, хранящимся в RFC-Editor. Первым RFC, явно объявленным официальным стандартом, был RFC 733. Официальные стандарты протоколов перечислены в следующих категориях:

Стандартный – установлен IESG в качестве стандартного протокола.
Черновик — в разработке, вероятно, это будет будущий стандартный протокол.
Proposed – ранний этап, предлагаемый протокол.
Исторические. Старые протоколы, обычно замененные или неиспользуемые.
Экспериментальный – протоколы исследований, задокументированные для удобства исследователей.

Шестой тип, информационные, — это протоколы, разработанные другими организациями, такими как официальные организации по стандартизации и коммерческие сетевые компании. Иногда они публиковались как RFC, чтобы предоставить стандартную ссылку для IETF. Последний список информационных протоколов можно найти в RFC 2500.

Редактор RFC присваивает каждому RFC уникальный серийный номер. После присвоения номера и публикации RFC никогда не отменяется и не модифицируется. Если документ требует изменений, авторы публикуют исправленный документ. Поэтому одни RFC заменяют собой другие. Замененные RFC считаются устаревшими, устаревшими или даже устаревшими [так в оригинале]. Вместе сериализованные RFC составляют непрерывный исторический отчет об эволюции интернет-стандартов и практик.

Процесс создания RFC отличается от процесса стандартизации официальных организаций по стандартизации, таких как Международная организация по стандартизации (ISO). Эксперты по интернет-технологиям могут представить Интернет-проект без поддержки со стороны внешнего учреждения.

RFC для отслеживания стандартов публикуются с одобрения IETF и обычно создаются экспертами, участвующими в рабочих группах, которые сначала публикуют проект в Интернете. Такой подход упрощает начальные раунды экспертной оценки до того, как документы превратятся в RFC.

Каждому протоколу присваивается статус "Требуется", "Рекомендуется", "Выборочный", "Ограниченное использование" или "Не рекомендуется" в порядке убывания приоритета. Только очень немногие основные протоколы имеют пометку «Обязательный»,

И, наконец, почти каждый день дурака (1 апреля) с 1989 года IETF публикует один или несколько сатирических или юмористических документов RFC. Эти специальные предложения следуют традиции июньского RFC 1973 года под названием ARPAWOCKY, в котором пародировалась бессмысленная поэма Льюиса Кэрролла «Бармаглот».

Проблема этого подхода заключается в нумерации страниц RFC, которая не используется на веб-страницах. Таким образом, строки заголовка и нижнего колонтитула, включенные в RFC как обычный текст, мешают потоку чтения в веб-браузере. Если доступен только веб-браузер, визуализация RFC в формате PDF часто является лучшим выбором, чем версия HTML.

Чтение документов RFC в GNU/Linux

При использовании системы GNU/Linux я предпочитаю извлекать текстовую версию RFC с помощью GNU wget, (слегка) переформатировать текст с помощью небольшого сценария AWK и sed и отображать его в XTerm соответствующего размера (или другом окне эмулятора терминала). ) с помощью меньшего пейджера. Это позволяет листать страницы, как в печатном RFC. Если система поддерживает UTF-8, например. используя относительно недавний дистрибутив GNU/Linux с конфигурацией по умолчанию, этот метод автоматически поддерживает использование UTF-8, как указано, например, в RFC 8187. Это можно сделать с помощью скрипта rfc-reader, который можно найти на этой странице:

Для новых RFC, опубликованных в формате XML с официальным (или оригинальным) HTML-рендерингом, более подходящим способом чтения RFC в настольной системе GNU/Linux является использование xdg-open из xdg-utils. чтобы открыть HTML-версию в веб-браузере:

Загрузить RFC-Reader

Я написал небольшой сценарий оболочки под названием rfc-reader для удобного чтения документов RFC в текстовом формате в GNU/Linux. Он использует метод, описанный выше.

Помимо ссылки на скачивание на этой странице, это часть моей коллекции инструментов для работы с отдельными файлами в репозитории git на GitHub. Журнал изменений для rfc-reader можно найти в виде журнала коммитов git.

Поскольку я использую GNU/Linux и предпочитаю GNU-версии Awk и sed, я тестирую только эти реализации. Реализации, отличные от GNU, часто хуже, и их использование может привести к поломке rfc-reader. Начиная с версии 0.40 для rfc-reader требуется оболочка GNU Bash.

Использование

Параметры

-h напечатать справку и выйти -V напечатать информацию о версии и выйти -L напечатать лицензию и выйти -t использовать текущий терминал вместо создания нового соответствующего размера

Примеры

Локальное хранилище RFC

Некоторые дистрибутивы GNU/Linux включают пакеты, содержащие RFC. rfc-reader ищет файлы RFC в следующих каталогах, используемых OpenSUSE и Debian/Ubuntu соответственно:

Если вам известны дополнительные места, используемые дистрибутивами GNU/Linux или другими операционными системами для предоставления локальных копий RFC, сообщите мне об этом.

Кэш для загруженных файлов RFC

Если один из каталогов $HOME/.rfc-reader/cache или $XDG_CACHE_DIR/rfc-reader (если $XDG_CACHE_DIR не установлен или установлен в пустую строку, вместо него используется $HOME/.cache) существует и доступен для чтения , rfc-reader будет искать там RFC-файлы. Если один из каталогов доступен для записи, rfc-reader будет использовать его для сохранения загруженных файлов RFC. Если оба каталога доступны для записи, rfc-reader предпочтет $XDG_CACHE_DIR/rfc-reader в качестве кэша загрузки, но все равно будет читать RFC из обоих каталогов.

Кэш загрузки, если он доступен, также используется для файлов поддержки, например, списка Черновиков Интернета ( all_id.txt ), используемого для определения последней версии Черновиков Интернета. , если не запрашивается конкретная версия.

Использовать без X-Windows

Если rfc-reader запускается без среды X-Windows, т. е. с пустой или неустановленной переменной среды DISPLAY, вместо открытия нового окна терминала подходящего размера rfc-reader будет использовать терминал, в котором он запущен. Если RFC разбит на страницы, а терминал слишком мал для отображения полной страницы RFC внутри выбранного пейджера, rfc-reader завершит работу с ошибкой ошибка.

Скриншоты

Использование XTerm и не только

Важные варианты

XTerm: -fn c-9x18 -fg green -bg black -bd green -g 72x59 less: -M -S (Полные параметры см. в самом скрипте.)

Использование терминала GNOME и не только

Важные варианты

Терминал GNOME: --hide-menubar --disable-factory --geometry 72x59 less: -M -S (полные параметры см. в самом сценарии.)

Примечание по использованию терминала GNOME

Запуск rfc-reader в качестве фонового задания не работает с терминалом GNOME. Кажется, идет гонка по настройке размеров терминала и запуску пейджера внутри терминала. Результатом является неправильный размер вывода внутри пейджера. В качестве обходного пути вы можете запустить rfc-reader на переднем плане, приостановить его (обычно CTRL+Z в терминале, из которого он был запущен), а затем сделать его фоновым процессом. с БГ .

Упомянутая выше проблема не возникает с XTerm.

О переформатировании RFC

В RFC используется формат, который хорошо работает при печати на бумаге. Он использует страницы с верхними и нижними колонтитулами. Все страницы примерно одинакового размера, который соответствует размеру бумаги большинства текстовых принтеров (но фактический размер страницы RFC немного отличается). Определение разрывов страниц и, следовательно, нумерация страниц для всех RFC на самом деле необходимо, чтобы гарантировать, что художественные рисунки, диаграммы и таблицы ASCII не будут затронуты разрывами страниц, автоматически вставляемыми при печати.

Проблема

Разбивка на страницы, особенно с использованием строк верхнего и нижнего колонтитула, плохо работает с переменными размерами экранов, окон терминала и шрифтов. Так называемые пейджеры (например, меньше) обычно адаптируются к текущему экрану, соответственно. размера окна и позволяют непрерывно прокручивать текст, теряя преимущества нумерации страниц. Хуже того, верхние и нижние колонтитулы прерывают чтение вместо того, чтобы ненавязчиво предоставлять справочную информацию. Поэтому необходимо нечто более сложное, чем просто просмотр исходного текстового файла RFC с помощью пейджера в окне терминала. Достаточно простой настройки как текстового файла RFC, так и окна терминала.

Следует отметить, что некоторые пейджеры, например, некоторые версии more и pg, поддерживают паузу на символах перевода страницы. Использование такого пейджера в достаточно большом терминале позволяет читать RFC постранично. К сожалению, более удобных пейджеров меньше (де-факто по умолчанию в GNU/Linux), и большинство из них не приостанавливается при подаче форм.

Решение

Текстовый документ, состоящий из страниц с фиксированным количеством строк, первая и последняя из которых используются в качестве верхнего и нижнего колонтитула, хорошо выглядит в пейджере, обеспечивающем точно такое же количество строк. Поскольку RFC имеют определенное максимальное количество строк (58) и максимальное количество символов в строке (72) [см. RFC 2223], использование области отображения текста такого размера должно работать нормально, но не все страницы в RFC имеют одинаковые длина. При печати использование символа перевода формы (FF, код ASCII 12) завершает страницу. Современные пейджеры обычно не используют это соглашение. Поэтому мой скрипт rfc-reader заполняет все страницы одинаковой длины (58 строк), обеспечивая чтение с разбиением на страницы на экране в окне терминала подходящего размера, показывающем вывод пейджера, и открывает окно терминала только правильного размера, при этом отформатированный текст отображается внутри пейджера.

Использование существующего терминала

Чтобы отобразить RFC в текстовом формате с пейджером внутри достаточно большого окна терминала, символ передачи формы должен быть расширен, чтобы заполнить терминал (исключая строку состояния пейджера). При использовании оболочки, которая устанавливает переменную среды LINES, например. GNU Bash это можно сделать следующим образом (используя less в качестве пейджера):

Кроме того, вы можете использовать env для сброса переменной среды DISPLAY и использовать rfc-reader. Таким образом, rfc-reader не может открыть новый терминал и вместо этого попытается использовать существующий, в котором он был запущен:

Альтернативное решение

Хотя я предпочитаю читать RFC-документы с разбивкой на страницы в постраничном просмотрщике, вы можете удалить разбиение на страницы из RFC и читать содержимое как один длинный поток текста. Для этого вы можете использовать инструмент rfcstrip (не путать с другим rfcstrip, упомянутым в RFC 8407, раздел 3.11) в сочетании с пейджером. Поскольку rfcstrip удаляет разрывы страниц (т. е. символы передачи формы) вместе с работающими верхними и нижними колонтитулами и использует сложное сжатие пустых строк, результаты представляют собой хороший ввод для любого пейджера, включая less, без необходимости специальных параметров:

rfcstrip RFC.txt | меньше

Будущие изменения формата RFC

Обзор и ссылки на сведения о планируемых изменениях формата (новых) документов RFC см. в разделе часто задаваемых вопросов об изменении формата RFC. Информацию о rfc-reader и чтении RFC нового формата в текстовых системах можно найти ниже.

RFC 6949 отменяет требования к нумерации страниц (раздел 3.3), поэтому сценарий rfc-reader потеряет свою полезность для новых RFC через какое-то время в будущем, но останется очень полезным для RFC, опубликованных в соответствии с RFC 2223. Сюда входят уже опубликованные RFC с правильной разбивкой на страницы, поскольку их повторная публикация в новом формате не планируется.

RFC 7990 именует XML с использованием словаря xml2rfc v3, как описано в RFC 7991, в качестве канонического формата для будущих документов RFC. Хотя XML – это текстовый формат, его неудобно читать как есть.

Текстовая версия XML RFC должна быть создана в одном из нескольких форматов публикации RFC. Эта версия с открытым текстом предназначена для версии RFC с низким уровнем точности, возможно, без рисунков вместо использования ASCII-арта, известного из предыдущих RFC. Эта текстовая версия может по-прежнему использовать нумерацию страниц, т.е., символы перевода формы, не более 58 строк на странице, но без верхних и нижних колонтитулов (см. создан, а RFC 6949 отменил требование нумерации страниц). Таким образом, rfc-reader может по-прежнему правильно форматировать новые RFC в виде обычного текста, но с небольшими преимуществами, если они вообще есть, по сравнению с простым использованием пейджера, который игнорирует значение канала формы символов. Возможно, лучший способ просмотреть эти RFC в виде простого текста в новом стиле — удалить потоки форм, сократить последовательные пустые строки до одной пустой строки (часто называемой сжатием). и используйте пейджер для просмотра результата. Это делается с помощью rfc-reader автоматически, если текст RFC не содержит символов передачи формы.

Изменение формата RFC

По состоянию на октябрь 2019 г. изменение формата документа RFC больше не относится к будущему.

Базовая нумерация страниц (RFC 7994, раздел 4)

Согласно разделу 4 RFC 7994, при отображении текста новых RFC в каноническом формате XML предполагалось использовать базовое разбиение на страницы, т. е. символы перевода формы в качестве разрывов страниц. , но ни для верхних, ни для нижних колонтитулов. В этом разделе были обещаны инструкции или сценарий того, как удалить эту базовую нумерацию страниц. Сценарий rfcstrip может удалить базовую нумерацию страниц из такого рендеринга текста. Он также может удалить классическую нумерацию страниц. Таким образом, скрипт уже доступен.

Поскольку базовая нумерация страниц означает просто добавление символов передачи формы, ее можно убрать с помощью совместимого с POSIX tr :

Но кажется, что новый текстовый рендеринг документов RFC в каноническом формате XML не использует нумерацию страниц, даже базовую. Чтобы подготовить текстовую версию для печати на текстовом принтере, может помочь использование pr для добавления нумерации страниц. Это, конечно, чревато появлением разрывов страниц внутри рисунков, поскольку pr не анализирует содержимое, чтобы избежать этого.

Новый формат RFC без разбиения на страницы для рендеринга текста (октябрь 2019 г.)

Глядя на RFC 8655, кажется, что нумерация страниц исключена из текстовой версии, по крайней мере, текстовая версия этого RFC, к которой обращались 25 октября 2019 г., не содержит никаких символов передачи формы. То же самое относится и к RFC 8651, первому RFC, опубликованному с использованием нового формата. RFC с наименьшим номером, использующий новый формат, похоже, RFC 8650.

Текстовая версия RFC больше не будет ограничиваться ASCII, а будет использовать кодировку UTF-8 с (в лучшем случае бесполезным для UTF-8) Unicode Знак порядка байтов ( BOM). Вероятно, лучше удалить BOM перед просмотром RFC в текстовом формате.

Просмотр (возможно, искаженного, поскольку рисунки и диаграммы могут быть опущены) текстовой версии будущего RFC можно было бы, таким образом, выполнить следующим образом: удалить спецификацию, а также строки с символом перевода формы, которые могут быть окружены пробелом, используемым для нумерации страниц, и использует функцию пейджера less для сжатия пустых строк. Сценарий rfc-reader автоматически удаляет предшествующую BOM в кодировке UTF-8.)

Сомнительная полезность рендеринга текста

Как отмечается в разделе Вопросы безопасности в RFC 7994, «[U]преднамеренные изменения текста в результате преобразования базового XML-файла могут, в свою очередь, привести к повреждению стандарта, практику или важную информацию о протоколе».

Версии этих будущих RFC в формате PDF/A-3 (см. RFC 7995) и HTML (см. RFC 7992 и RFC 7993), созданные на основе канонической XML-версии, вероятно, являются единственными реалистичными вариантами чтения всего содержимого документа. будущий RFC, включая рисунки и диаграммы. Это, конечно, требует использования сложного программного обеспечения и графических дисплеев.

Таким образом, 50-летие серии RFC в 2019 году знаменует собой конец целой эпохи.

Читайте также:


Какая программа не может открыть файл html

Экспорт C в Excel

Расширение оболочки Corel Graphics для Windows, что это за программа

Как удалить bin-файл, который не удаляется

Размытие в движении после эффектов не работает