RFC: 2223
Оригинал: Instructions to RFC Authors
Предыдущие версии: RFC 825, RFC 1111, RFC 1543
Категория: Информационный
Дата публикации:
Авторы: ,
Перевод: Колесников Иван

Статус данной статьи

Данная статья предоставляет информацию для сообщества Интернета. Данная статья не является каким-либо стандартом Интернета. Распространение данной статьи не ограничивается.

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

Авторское право (C) за Обществом Интернета (1997). Все права защищены.

Содержание

1. Введение

Данный Запрос комментариев (RFC) предоставляет информацию о подготовке RFC и определенных правилах, связанных с публикацией RFC.

Серия статей RFC охватывает широкий круг интересов. Основные темы - это Интернет и обвязка протокола TCP/IP. Однако, любая тема, имеющая отношение к компьютерным коммуникациям может быть приемлема, по усмотрению Редактора RFC.

Статьи, претендующие на статус RFC, могут быть поданы кем угодно. Один большой прародитель статей, которые стали RFC-шками, это Проектный совет Интернета (англ. Internet Engineering Task Force, IETF). Рабочие группы IETF (working groups, WGs) совершенствуют свои рабочие записи (известные как проекты документации Интернета, англ. Internet Drafts или I-Ds) до тех пор пока не осознают их готовность для публикации, затем статьи проверяются Проектной группой руководителей (по вопросам) Интернета (Internet Engineering Steering Group, IESG) и в случае одобрения отправляются из IESG Редактору RFC.

Большинство статей, направленных Редактору RFC из независимых источников, будут проверены группой IESG на возможную взаимосвязь с разработками Рабочих групп IETF.

RFC распространяются по сети как хранящиеся общедоступные файлы, а также отправляется оповещение списку рассылки, сообщающее, о доступности статьи.

Непрерывно доступные файлы копируются заинтересованными людьми и печатаются или выкладываются на их сайте на их же аппаратном обеспечении. Это означает, что формат постоянно доступных файлов должен соответствовать ограничениям широкого спектра печатающего и отображающего оборудования. (RFC-шки могут также быть получены по электронной почте в ответ на электронный почтовый запрос или RFC могут быть найдены при помощи ключевых слов и средств поиска в базах данных, таких как Gopher, Wais или Всемирная паутина (World Wide Web, WWW)).

RFC традиционно публиковались и продолжают публиковаться в тексте формата ASCII.

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

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

Однако, многие читатели RFC открывают эти документы по сети и используют различные текстовые программы (например, emacs, grep) для поиска в них. Часто краткие выдержки из RFC добавляются в электронные письма. Такие операции пока еще не осуществимы с файлами формата PostScript.

Системы, выдающие PostScript, менее стандартизованы чем хотелось бы, и некоторые системы обработки документов, которые заявляют что выдают PostScript, на самом деле выдают нестандартизованный результат.

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

2. Политика редактирования

Документы, претендующие стать RFC, рассматривает Редактор RFC и возможно другие рецензенты, выбранные им.

В результате такого обзора могут быть предложены автору некоторые изменения в документ перед публикацией.

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

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

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

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

Документы, подготовленные как RFC, в соответствии с порядком стандартизации должны быть утверждены группой IESG перед отправкой Редактору RFC. Установленная процедура такова, что когда IESG завершает работу над документом, который становится стандартизованным RFC, тогда будет (отправляться) сообщение из секретариата IESG Редактору RFC. Как правило, обсуждаемые документы (уже) являются Проектами Интернет-документов. Сообщение обычно содержит точный указанный Проект Интернет-документа (согласно имени файла). Редактор RFC обязан понять, что только этот файл подлежит обработке для получения статуса RFC. Если у авторов есть небольшие поправки к тексту, то они должны быть отправлены Редактору RFC отдельно (или как вывод утилиты сравнения diff), не отправляйте новую версию документа.

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

Следствием этого является то, что Редактор RFC сначала обрабатывает ASCII-версию сообщения для публикации в качестве RFC. Если автор пожелает добавить на данном этапе PostScript-версию, которая совпадает с ASCII-версией (и Редактор RFC согласен с этим), тогда постскриптовая версия будет добавлена в архивы RFC и предоставлена сообществу.

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

3. Правила форматирования

Для обхода трудностей, связанных с распространением, установлены нижеследующие правила для двух допустимых форматов RFC: ASCII и Постскрипта.

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

Вы должны предоставить редактируемый электронный документ Редактору RFC. Редактор может потребовать или сделать (сам) минимальные изменения формата или стиля и вставит официальный номер RFC.

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

3.a. Правила форматирования в ASCII

  • Кодировкой символов является ASCII.
  • Каждая страница должна состоять из 58 строк, завершаясь символом окончания страницы на новой строке.
  • Каждая строка должна состоять из 72 символов, завершаясь символами возврата каретки и окончания строки.
  • Не допускается выделение шрифта (или подчеркивание).
  • Указанные значения "высоты" и "ширины" включают любые верхние, нижние колонтитулы, номера страниц или левосторонние отступы.
  • Не заполнять текст излишними пробелами, поставленных для выравнивания по правой границе.
  • Не использовать перенос слов по слогам на правой границе.
  • Не использовать подстрочные примечания. Если такие примечания необходимы, то разместите их в конце раздела или в конце документа.
  • Использовать единичные пробелы внутри абзаца и одну пустую строку между абзацами.

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

RFCшки в ASCII-формате могут быть переданы Редактору по электронной почте (или как расшаренные файлы) в любом готовом для публикации формате или в nroff'е. Если вы планируется передать документ в nroff'е пожалуйста посоветуйтесь сначала с Редактором RFC.

3.b. Правила форматирования в ПостСкрипте

  • Стандартный размер страницы 8,5 на 11 дюймов.
  • Отступ в 1 дюйм со всех сторон (сверху, снизу, слева и справа).
  • Основной текст должен иметь высоту символа не менее чем 10 точек и межстрочный интервал в 12 точек.
  • Примечания и подписи изображений не меньше чем 8 точек с межстрочным интервалом в 9,6 точек.
  • Приемлемы три шрифта: Helvetica, Times Roman и Courier. Плюс их жирные и курсивные модификации. Эти три являются стандартными шрифтами на большинстве ПостСкриптовых принтерах.
  • Готовьте диаграммы и изображения основываясь на простейших общих настройках ПостСкрипта. Ориентируйтесь на функциональность и характерстики памяти рядового ПостСкриптового принтера.
  • Следующие ПостСкриптовые команды не должны быть использованы: initgraphics, erasepage, copypage, grestoreall, initmatrix, initclip, banddevice, framedevice, nulldevice and renderbands.

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

Эти постскриптовые правила могут быть изменены и дополнены по мере накопления опыта.

RFC в формате PostScript могут быть переданы Редактору по электронной почте (или как доступные по сети файлы). Если вы планируется передать документ в посткрипте пожалуйста посоветуйтесь сначала с Редактором RFC.

Помните, с тех пор как текстовая ASCII-версия является первичной, постскриптовая версия должна совпадать с текстовой. Редактор RFC должен утвердить, что постскриптовая версия идентична ASCII-версии перед тем как постскриптовая версия будет опубликована.

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

Выделяются верхний колонтитул первой страницы, скользящий верхний колонтитул и скользящий нижний колонтитул.

4.a. Первая страница

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

  • Рабочая группа по сетям
  • Это традиционное название группы, которая создаёт выпуски RFC. Указывается на первой строке с левой стороны колонтитула.
  • Вопрос для обсуждения (RFC): nnnn
  • Объявляет статью вопросом для обсуждения и сообщает номер. Указывается на второй строке с левой стороны. Официальный номер вставляется в последний момент перед публикацией редактором RFC.
  • Автор
  • Имя автора (только первый инициал и фамилия) указывается на первой строке с правой стороны колонтитула.
  • Организация
  • Место работы автора, указывается на второй строке с правой стороны.
  • Дата
  • Это месяц и год публикации RFC. Указывается на третьей строке справа.
  • Дополняет или Заменяет
  • Если этот RFC дополняет или заменяет другой RFC, то это указывается третьей строкой с левой стороны колонтитула.
  • Категория
  • Категория даного RFC, одна из: стандартизован, лучший современный опыт, информационный или экспериментальный. Указывается на третьей (если нет указания на дополнение или замену) или четвертой строке с левой стороны.
  • Дополнительная нумерация
  • Дополнительная нумерация в цикле статей RFC включает подциклы: FYI (For Your Information, для вашего сведения, RFC 1150) [4], BCP (Best Current Practice, лучший современный опыт, RFC 1818) [5] и STD (Standard, стандарт, RFC 1311) [6]. Размещается на левой стороне.
  • Заголовок
  • Заголовок проставляется по центру, ниже всего колонитула. Пропуски или точки в загловке не допускаются. Если (у статьи) авторов несколько и если несколько авторов из разных организаций, то правая часть колонтитула может быть дополнена строками, чтобы вместить их (всех) и чтобы сопоставить авторов и организации должным образом.

4.b. Скользящий верхний колонтитул

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

4.c. Скользящий нижний колонтитул

Скользящий нижний колонтитул однострочный (на всех страницах), содержит слева фамилию автора, по центру - категорию и справа номер страницы ([Page N]).

5. Раздел статуса

Каждый RFC должен содержать на своей первой странице раздел "Статус данной статьи", который состоит из двух частей: (1) абзац, описывающий категорию RFC, и (2) условия распространения.

Содержанием этого раздела будет одно из четырех следующих высказываний.

  • Стандартизованный
  • "Данный документ предоставляет протокол Интернет-стандартизации сообществу Интернета и требует обсуждения и предложений по улучшению. Пожалуйста, смотрите актуальную версию "Официальных стандартов протоколов Интернета" (STD 1) для (уточнения) стандартизационного состояния и статуса данного протокола. Распространение данной статьи не ограничивается."
  • Лучший современный опыт
  • "Данный документ предоставляет лучший современный опыт в Интернете сообществу Интернета и требует обсуждения и предложений по улучшению. Распространение данной статьи не ограничивается."
  • Экспериментальный
  • "Данная статья предоставляет экспериментальный протокол сообществу Интернета. Данная статья не является каким-либо стандартом Интернета. Требуются обсуждение и предложения по улучшению. Распространение данной статьи не ограничивается."
  • Информационный
  • "Данная статья предоставляет информацию для сообщества Интернета. Данная статья не является каким-либо стандартом Интернета. Распространение данной статьи не ограничивается."

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

Сразу после раздела статуса размещается фраза "Авторское право (C) за Обществом Интернета (дата). Все права защищены." Также см. раздел 11 чтобы посмотреть полную фразу, которая должна размещаться в конце документа.

7. Раздел введения

Каждый RFC должен иметь раздел введения, который (помимо прочего) объясняет предпосылки для (создания) RFC и (при необходимости) описывает область применения описанного протокола.

Обычно им будем раздел "аннотация" из проекта Интернет-стандарта. Если RFC не основан на таковом, то возможны следующие варианты:

  • Протокол

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

    или

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

  • Обсуждение
  • Назначением данного RFC является заострение внимания на определенных проблемах в Интернете и возможных методах решения. Ни одно из внесенных решений не предлагается в качестве стандарта Интернета. Более того, будем надеяться, что будет достигнуто единое мнение в качестве соответствующего решения таких проблем, ведущее в конечном итоге к принятию стандартов.
  • Заинтереснованность
  • Данный RFC предоставляется членам Интернет-сообщества для того, чтобы выяснить их реакцию на предложения, содержащиеся в нем. В то время как обсуждаемые вопросы могут не иметь прямого отношения к исследуемым проблемам Интернета, они могут быть интересны некоторым разработчикам и администраторам.
  • Сообщение статуса
  • Соответствуя необходимости озвучания обновляющейся информации о состоянии и ходе выполнения различных проектов в Интернет-сообществе, такой RFC выпускается для удобства участников сообщества. Информация, содержащаяся в таком документе верна на момент публикации, но склонна изменяться. Последующие RFC будут отражать эти изменения.

Эти абзацы не обязательны для исполнения точь-в-точь, но общая направленность RFC должна быть ясна.

8. Раздел списка литературы

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

В большинстве стандартизованных документов ряд слов используется для обозначения определенных характеристик. Этими словами часто спекулируют. BCP 14 и RFC 2119 [3] определяют как данные слова обязаны пониматься в документах IETF.

9. Раздел вопросов безопасности

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

10. Раздел адреса автора

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

11. Раздел авторских прав

Из BCP 9, RFC 2026 [2]: "Следующее уведомление об авторских правах и (заявление) отказа от отвественности (последствий использования) нужно включать во всю, связанную со стандартизацией ISOC, документацию." Следующую формулировку следует размещать на последней странице RFC под названием "Полное заявление авторских прав":

"Авторское право (C) за Обществом Интернета (дата). Все права защищены.

Данный документ и его переводы можно копировать и передавать кому-либо, и производные работы, которые описывают или иным образом объясняют его или помогают в его применении, можно выполнять, копировать, публиковать и распространять, полностью или частично, без каких-либо ограничений, при условии, что приведенное выше уведомление об авторских и данный абзац включены во все такие копии и производные работы. Однако, сам данный документ не может быть изменен каким-либо способом, например удалением уведомления об авторских правах или ссылок на ISOC или другие организации Интернета, за исключением случаев, необходимых для развития стандартов Интернета, в которых процедуры в отношении авторских прав, определенные в процессе стандартизации Интернет, должны быть соблюдены, или (за исключением случаев) необходимых для перевода его на языки, отличные от английского.

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

Данный документ и содержащаяся в нем информация предоставляется по принципу "что есть, то и есть" и ISOC, и IETF ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ явных или подразумеваемых, включая но не ограничиваясь любыми гарантиями, что ИСПОЛЬЗОВАНИЕ публикуемой информации НЕ НАРУШИТ какие-либо ПРАВА или любые подразумеваемые ГАРАНТИИ рыночной стоимости или (гарантии) применения для определенной цели."

12. Взаимосвязь с другими RFC

Иногда, RFC добавляет информацию к теме, обсужденной в предыдущем RFC, или полностью заменяет более ранний RFC. Существуют два термина, которые используются для этих случаев, соответственно: Дополняет и Отменяет. Документ, который отменяет более ранний документ, является самостоятельным. Документ, который лишь дополняет более ранний документ не может быть отдельным документом; это то, что должно быть добавлено или вставлено в ранее созданный документ и имеет явно определенную пользу. Термины Вытесняет (Supercedes) и Заменяет (Replaces) более не используются.

  • Дополняет (Updates)
  • Будет использоваться как указатель из нового элемента, который не может использоваться в одиночку (т.е. единица, которая дополняет предыдущий документ), чтобы сослаться на предыдущий документ. Более новая публикация - это часть, которая дополнит или будет добавлена к существующему документу; напр., дополнение или отдельная дополнительная информация, которая должна быть добавлена к исходному документу.
  • Отменяет (Obsoletes)
  • Будет использоваться, чтобы сослаться на более ранний документ, который заменяется данным документом. Данный документ содержит или пересмотренную информацию или всю ту же информацию плюс некоторая новая информация, какой бы пространной или сжатой эта новая информация ни была, т.е. этот документ может использоваться самостоятельно, без привязки к старшему документу.

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

В перечнях RFC-шек или RFC-индексе (но не в самих RFC) нижеследующие (термины) могут быть использованы в описании более старых документов для ссылки на более новые документы:

  • Отменяется из-за (Obsoleted-by)
  • Используется для ссылки на новый документ(ы), который заменяет прежний документ.
  • Дополняется из (Updated-by)
  • Используется для ссылки на новый раздел(а), который должен быть добавлен к существующему, все еще использующемуся, документу.

13. Процесс стандартизации прокола

Смотрите текущую (версию) статьи "Официальные стандарты протоколов Интернета" (STD 1, RFC 2200) для (получения) точных данных по стандартам протоколов и их публикациям [1].

Установленная процедура такова, что когда IESG завершает работу над документом, который становится стандартизованным RFC, (только) тогда будет (отправляться) сообщение из секретариата IESG Редактору RFC. Как правило, обсуждаемые документы (уже) являются Проектами Интернет-документов. Сообщение обычно содержит точный указанный Проект Интернет-документа (согласно имени файла). Редактор RFC обязан понять, что только этот файл подлежит обработке для получения статуса RFC. Если у авторов есть небольшие поправки к тексту, то они должны быть отправлены Редактору RFC отдельно (или как вывод утилиты сравнения diff), не отправляйте новую версию документа.

14. Контакты

Чтобы связаться с Редактором RFC отправьте электронное письмо на: "[email protected] ".

15. Списки рассылки

Оповещения об RFC рассылаются по двум спискам почтовых (адресов): список "IETF-Announce" и список "RFC-DIST". Не нужно быть в обоих списках.

Чтобы присоединиться (или выйти) к списку "IETF-Announce" отправьте сообщение на [email protected]

Чтобы присоединиться (или выйти) к списку "RFC-DIST" отправьте сообщение на [email protected]

16. Индекс RFC

Несколько организаций ведут файлы индекса RFC, обычно используя имя файла .html-index.txt". Содержание такого файла, скопированного с одного сайта, может отличаться от скопированного с другого сайта.

17. Вопросы безопасности

Данный RFC не поднимает никаких вопросов безопасности (хотя, см. Раздел 9).

18. Список литературы

[1] Postel, J., Editor, «Internet Official Protocol Standards», STD 1, RFC 2200, Июнь 1997.
[2] Bradner, S., «The Internet Standards Process -- Revision 3», BCP 9, RFC 2026, October 1996.
[3] Scott Bradner, «Ключевые слова для обозначения уровня требований в RFC», RFC 2119, Март 1997.
[4] Malkin, G., and J. Reynolds, «F.Y.I. on F.Y.I Introduction to the F.Y.I. Notes», FYI 1, RFC 1150, Март 1990.
[5] Postel, J., Li, T., and Y. Rekhter, «Best Current Practices»,BCP 1, RFC 1818, Август 1995.
[6] Postel, J., Editor, «Introduction to the STD Notes», RFC 1311, Март 1992.

19. Адреса авторов

Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: +1 310-822-1511
Fax: +1 310-823-6714
EMail: [email protected]

Joyce K. Reynolds
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: +1 310-822-1511
Fax: +1 310-823-6714
EMail: [email protected]

20. Приложение: nroff-макрос для RFC

Как правило мы используем самые простейшие функции nroff. Мы используем макрос "ms" так: "nroff -ms input-file > output-file". Однако, мы не может заставить nroff правильно выполнять установку символа новой страницы после последней видимой строки на странице и без лишних символов конца строки перед первой видимой строкой на следующей странице. Мы хотим:

последняя видимая строка на странице i
^L
первая видимая строка на странице i+1

Пришлось хакнуть всё это дело. Мы используем perl-скрипт, названный "fix.pl". В итоге команда для обработки файла становится такой:

nroff -ms input-file | fix.pl > output-file

Ныне существующий perl-скрипт такой:

#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#! /local/bin/perl
# fix.pl  17-Nov-93  Craig Milo Rogers at USC/ISI
#
#     Стилистические указания для RFCшек требуют от страниц быть
# разделенными следующим образом: <последняя-непустая-строка>
# <строка-начала-новой-страницы><первая-непустая-строка>.
# К сожалению, NROFF не хочет выдавать такую последовательность.
# Данный скрипт правит документы формата RFC путем поиска сочетания
# "FORMFEED[Page", заменой "FORMFEED" на пробелы, добавлением строки 
# начала новой страницы и удалением невидимого символа перед следующим
# видимым символом.
#
#     Есть одно отличие между выводом этого скрипта и программами "fix.sh"
# и "pg" его заменяющими: этот скрипт вставляет новую строку после
# конца страницы после последней страницы в файле, в то время как
# более ранние программы оставляли одиночным символ конца страницы в 
# качестве последнего символа в файле. Чтобы получить одиночные
# символы конца страницы раскомментируйте вторую команду замещения. 
# Чтобы убрать последний символ конца страницы раскомментируйте третью 
# команду замещения.
#
#     Данный скрипт должен запускаться в качестве фильтра следующим
# образом:
#
# nroff -ms input-file | fix.pl > output-file
#
#     Когда обрабатываете данным скриптом пожалуйста учитывайте следующие
# моменты:
#
# 1) ISI хранит perl в "/local/bin/perl"; ваша система возможно хранит
# его в другом месте.
# 2) На системах с CRLF-форматированием окончаний строк, символы "\n"
# возможно придется заменить на \r\n".
$* = 1;                             # Включаем многострочные шаблоны.
undef $/;                           # Читаем весь файл единым потоком.
while (<>) {                        # Прочитываем полностью входящий файл.
    s/FORMFEED(\[Page\s+\d+\])\s+/        \1\n\f\n/g;
                                    # Правим окончания страниц.
#    s/\f\n$/\f/;                   # Нужен одиночный символ страницы в
                                    # конце?
#    s/\f\n$//;                     # Не нужен символ страницы в конце?
    print;                          # Печатаем измененный файл.
}
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Данный скрипт можно также скопировать с: ftp://ftp.isi.edu/in-notes.html-editor/fix.pl

И вот для демонстрации используемых возможностей nroff, приведен пример статьи, подготовленной в стилистике RFC:

.pl 10.0i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LF Waitzman
.ds RF PUTFFHERE[Page %]
.ds CF
.ds LH RFC 1149
.ds RH 1 April 1990
.ds CH IP Datagrams on Avian Carriers
.hy 0
.ad l
.in 0
Network Working Group                                        D. Waitzman
Request for Comments: 1149                                       BBN STC
                                                            1 April 1990
.ce
A Standard for the Transmission of IP Datagrams on Avian Carriers
.ti 0
Status of this Memo
.fi
.in 3
This memo describes an experimental method for the encapsulation of IP
datagrams in avian carriers.  This specification is primarily useful
in Metropolitan Area Networks.  This is an experimental, not recommended
standard.  Distribution of this memo is unlimited.
.ti 0
Overview and Rational
Avian carriers can provide high delay, low throughput, and low
altitude service.  The connection topology is limited to a single
point-to-point path for each carrier, used with standard carriers, but
many carriers can be used without significant interference with each
other, outside of early spring.  This is because of the 3D ether space
available to the carriers, in contrast to the 1D ether used by
IEEE802.3.  The carriers have an intrinsic collision avoidance system,
which increases availability.  Unlike some network technologies, such
as packet radio, communication is not limited to line-of-sight
distance.  Connection oriented service is available in some cities,
usually based upon a central hub topology.
.ti 0
Frame Format
The IP datagram is printed, on a small scroll of paper, in
hexadecimal, with each octet separated by whitestuff and blackstuff.
The scroll of paper is wrapped around one leg of the avian carrier.
A band of duct tape is used to secure the datagram's edges.  The
bandwidth is limited to the leg length.  The MTU is variable, and
paradoxically, generally increases with increased carrier age.  A
typical MTU is 256 milligrams.  Some datagram padding may be needed.
Upon receipt, the duct tape is removed and the paper copy of the
datagram is optically scanned into a electronically transmittable
form.
.ti 0
Discussion
Multiple types of service can be provided with a prioritized pecking
order.  An additional property is built-in worm detection and
eradication.  Because IP only guarantees best effort delivery, loss of
a carrier can be tolerated.  With time, the carriers are
self-regenerating.  While broadcasting is not specified, storms can
cause data loss.  There is persistent delivery retry, until the
carrier drops.  Audit trails are automatically generated, and can
often be found on logs and cable trays.
.ti 0
Security Considerations
.in 3
Security is not generally a problem in normal operation, but special
measures must be taken (such as data encryption) when avian carriers
are used in a tactical environment.
.ti 0
Author's Address
.nf
David Waitzman
BBN Systems and Technologies Corporation
BBN Labs Division
10 Moulton Street
Cambridge, MA 02238
Phone: (617) 873-4323
EMail: [email protected]

21. Полное заявление об авторских правах

Авторское право (C) за Обществом Интернета (1997). Все права защищены.

Данный документ и его переводы можно копировать и передавать кому-либо, и производные работы, которые описывают или иным образом объясняют его или помогают в его применении, можно выполнять, копировать, публиковать и распространять, полностью или частично, без каких-либо ограничений, при условии, что приведенное выше уведомление об авторских и данный абзац включены во все такие копии и производные работы. Однако, сам данный документ не может быть изменен каким-либо способом, например удалением уведомления об авторских правах или ссылок на ISOC или другие организации Интернета, за исключением случаев, необходимых для развития стандартов Интернета, в которых процедуры в отношении авторских прав, определенные в процессе стандартизации Интернет, должны быть соблюдены, или (за исключением случаев) необходимых для перевода его на языки, отличные от английского.

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

Данный документ и содержащаяся в нем информация предоставляется по принципу "что есть, то и есть" и ISOC, и IETF ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ явных или подразумеваемых, включая но не ограничиваясь любыми гарантиями, что ИСПОЛЬЗОВАНИЕ публикуемой информации НЕ НАРУШИТ какие-либо ПРАВА или любые подразумеваемые ГАРАНТИИ рыночной стоимости или (гарантии) применения для определенной цели.

2007 - 2022 © Русские переводы RFC, IETF, ISOC.