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

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

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

последняя видимая строка на странице i
первая видимая строка на странице 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/rfc-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

A Standard for the Transmission of IP Datagrams on Avian Carriers

.ti 0
Status of this Memo

.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

.ti 0

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

David Waitzman
BBN Systems and Technologies Corporation
BBN Labs Division
10 Moulton Street
Cambridge, MA 02238

Phone: (617) 873-4323

EMail: dwaitzman@BBN.COM
2007 - 2017 © Русские переводы RFC, IETF, ISOC.