RMNT.RU  /  Нормативные документы  /  СанПиНы, руководящие документы  /  РД

РД 45.134-2000, часть 11



4 . Требования к структуре статей


4. 1. Формат электронной статьи должен соответствовать формату, описанному

RFC 822 [2] .


4. 2. Обязательно должны присутствовать поля заголовка:


from;

date;

newsgroups;

subject;

message-id;

path.


4. 3. Кроме указанных в п. 4. 2. могут присутствовать поля заголовка:


followup-to;

expires;

reply-to;

sender;

references;

control;

distribution;

keywords;

summary;

approved;

lines;

xref;

organization.


Обязательные поля заголовка статьи должны интерпретироваться следующим образом (определения элементов, используемых в выражениях описания, приведены в RFC 822 [2] ):


1. f_from ::= ( domain <SP> [ "(" full_name ") ] ) /

( full_name <SP> "<" domain ">")

domain ::= <электронный адрес отправителя>

full_name ::= <Полное имя отправителя. Может состоять из любых печатных символов ASCII , кроме "(" , ")" , "<" , ">" , "," , ":" , "@" , "!" , "/" , "=" , ";">


2. Date ::= Day "," <SP> DD <SP> Mon <SP> YY <SP> HH ":" MM ":" SS <SP>

TIMEZONE


Элементы данного поля должны соответствовать RFC 822 [2]


3. Newsgroups ::= 1#Newsgroup

Newsgroup ::= <Имя существующей группы новостей. Не должно содержать слова "all" в качестве элемента иерархического имени>


4. Subject ::= ["Re:"] S

S ::= <Краткое описание темы сообщения.>


"Re:" должно быть указано в случае, если данная статья является ответом на другую статью. При этом требуется обязательное наличие поля References.


5. Message-ID ::= "<" addr-spec ">" ; идентификатор статьи

addr-spec ::= local-part "@" domain

domain - полное доменное имя узла, с которого сообщение поступило в сеть.

Выражение local-part должно быть уникальным для всех статей в данном домене.


6. Path ::= <путь, который статья прошла до достижения данной системы>


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


7. References ::= * ( <SP> Message-ID) ;









Приложение 7

Технические требования к техническим средствам службы доступа к информационным ресурсам по протоколу fTP





1. Область применения


Настоящее приложение описывает технические требования к ТС службы доступа к информационным ресурсам а по протоколу NNTP в соответствии с RFC 959 [27] .

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

Не все функции, содержащиеся в данном приложении, обязательны для ТС службы доступа к информационным ресурсам по протоколу FTP , но если они выполняются , то их реализация должна соответствовать настоящему приложению.



2. Функциональные требования к взаимодействию сервера FTP и клиента FTP

2.1. Модель FTP


Сервер FTP должен взаимодействовать с клиентом FTP в соответствии с основной (обязательной) и дополнительной (необязательной) моделью FTP.

2.1.1. Схема основной модели FTP


Схема основной модели FTP показана на рис. 1.




Рис. 1. Основная модель использования FTP

2.1.2. Схема дополнительной модели FTP


Схема дополнительной модели FTP показана на рис. 2.





Рис. 2. Дополнительная модель использования FTP




2.2. Управляющее соединение


В ТС FTP должно быть реализовано управляющее соединение.

Управляющее соединение FTP устанавливается клиентом по протоколу TCP с использованием порта L на стороне сервера и порта U на стороне клиента. По умолчанию L=21.


2.2.1. Процедура установления соединения


Интерпретатор протокола сервера "слушает" порт TCP L. Клиент инициирует полнодуплексное управляющее соединение.




При передаче данных между серверами (п. 3.1.2.) PI клиента устанавливает управляющее соединение с обоими серверами.

На рис. 3 представлена процедура установления управляющего соединения дополнительной модели работы FTP.



PI клиента - сервер A

PI клиента - сервер B

C->A

Connect

C->B

Connect

C->A

PASV



A->C

227 Entering passive mode A1, A2, A3, A4, a1, a2





C->B

PORT A1, A2, A3, A4, a1, a2



B->C

200 Okay

C->A

STOR

C->B

RETR





B->A Connect to host-A, host-B


Рис. 3. Процедура установления управляющего соединения дополнительной модели FTP


2.2.2. Управление соединением


Установка, разрыв и управление соединением должно выполняться по протоколу Telnet.

Управляющее соединение должно быть закрыто сервером по запросу клиента.


2.3. Соединение данных


В ТС FTP должно быть реализовано соединение данных.


Соединение данных должно быть установлено на соответствующем порте перед передачей данных и выбраны соответствующие параметры передачи. DTP клиента и DTP сервера имеют порт по умолчанию - U-1 и L-1 соответственно. Длина передаваемых байтов - 8 бит.

2.3.1. Процедура установления соединения.


Установление соединения инициирует сервер.

Пассивный DTP (DTP клиента или DTP второго сервера) слушает порт данных перед тем, как послать команду запроса передачи. Команда запроса передачи FTP определяет направление передачи данных. Сервер, получив запрос, инициирует соединение данных на порту. После установления соединения начинается передача данных между DTP и PI сервера. Сервер посылает подтверждающий ответ процессу PI клиента.

Инициировать изменение портов, отличных от установленных по умолчанию, может только PI клиента. (команда PORT).

2.3.2. Процедура разрыва соединения.


Закрытие соединения, как правило, инициирует сервер.

Исключением является случай, когда DTP клиента посылает данные в режиме, определяющем закрытие соединения для индикации EOF. Сервер должен закрыть соединение при следующих условиях:

1. сервер выполнил передачу данных в режиме, требующем закрытия для индикации EOF.

2. сервер получил команду ABORT от клиента

3. спецификация порта изменена командой от клиента

4. управляющее соединение закрыто

5. произошла невосстановимая ошибка


В остальных случаях сервер инициирует закрытие соединения данных посылкой процессу клиента ответов 250 или 226.


2.3.3. Управление соединением данных


2.3.3.1.На стороне сервера номер порта соединения данных по умолчанию должен быть на 1 меньше номера порта управляющего соединения.


2.3.3.2. Процедура согласования портов данных, отличных от установленных по умолчанию (нестандартных)


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


2.3.3.3. Переустановка соединения данных


При использовании режима передачи данных stream mode конец файла определяется закрытием соединения. Проблема передачи нескольких файлов может иметь два решения:

1. установка нестандартного порта.

2. использование другого режима передачи данных

2 .3.4. Режимы передачи данных


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

Обязательно должны быть реализованы stream mode и block mode.


2.3.4.1. Stream mode (режим потока).


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

Если файл имеет структуру записей (структурирован по записям), символы EOR и EOF индицируются двухбайтовым кодом. Причем первым байтом должен быть escape-символ, а второй байт должен быть 1 (единица в менее значащем бите) для EOR и 2 (единица во втором бите) для EOF. Последовательность из escape-символа и символа 3 (два младших бита равны 1) означает одновременное присутствие EOR и EOF.

Если файл неструктурирован, символ EOF индицируется передающим узлом путем закрытия соединения данных. Все передаваемые байты являются байтами данных.


Данный тип передачи устанавливается по умолчанию.


2.3.4.2. Block mode - поблочный режим


Файл передается как серия блоков данных с заголовками.

Длина заголовка - 3 байта - 16 младших бит занимает поле counter, 8 старших бит - descriptor.


Descriptor 8 бит

Count 16 бит


Заголовок содержит поля:

1. Поле счета (counter) - показывает общую длину блока в байтах (без учета заголовка), тем самым определяя начало следующего блока (блоки передаются один за другим без пауз и разрывов)

2. Поле описателя (дескриптора) (descriptor):



Код

Значение

128

EOF - последний блок файла

64

EOR - последний блок записи

16

restart marker - в блоке данных содержится символ рестарта

32

suspect data - передаваемые данные в блоке могут содержать ошибку


Допускается наличие нескольких дескрипторов в одном блоке (коды логически складываются - операция "И").

Данными маркера рестарта может быть набор печатных символов используемого алфавита (NVT-ASCII например), в который не должен входить пробел (Space).


2.3.4.3. Compressed mode - режим сжатия


Посылается три вида информации - регулярные данные (в виде строки байтов), сжатые данные (состоящие из репликаторов и заполнителей) и управляющая информация в виде двухбайтовой escape-последовательности. Если посылаются от 1 до 127 байт регулярных данных, этим данным должен предшествовать байт, в самом левом бите которого установлен 0, а в остальных содержится число байт регулярных данных.



2.3.4.3.1. Блок несжатых данных


1

7


8


8

0

n


d(1)


d(n)




n байт данных



2.3.4.3.2. Блок репликатора


Для сжатия строки из n репликаций (копий) байта данных d посылаются два байта:


2

6


8

1

0

n


d


2.3.4.3.3. Блок заполнителя


Строка из n байтов заполнителя может быть сжата в один байт. Байт заполнителя зависит от типа представления данных (для ASCII и EBCDIC - это <SP> (Space, 32 - ASCII, 64-EBCDIC), для типов Image и Local - 0).



2

6

1

1

n


Escape - последовательность - это сдвоенные байты, первый из которых - это escape-символ - 0, а второй содержит код дескриптора, определенный в Block Mode. Код дескриптора имеет то же значение, что и в Block Mode и применяется к строке байтов.



3. Требования к типам данных


При передаче информации по соединению данных могут использоваться следующие типы данных как: ASCII, EBCDIC, IMAGE и LOCAL, а также могут поддерживаться структуры данных: file, record, page. Обязательными для реализации являются типы данных ASCII и IMAGE, а также структуры данных file и record. Должен поддерживаться режим управления форматом Nonprint.

3.1. Типы данных


Тип данных определяет размер логических байтов и кодировку передаваемых байтов. Длина передаваемых байтов всегда составляет 8 бит. Размер логических байтов в типах ASCII, EBCDIC и IMAGE составляет 8 бит, а в типе LOCAL определяется параметром команды TYPE.


Могут поддерживаться следующие типы данных:

1. тип ASCII (NVT-ASCII). Этот тип должен использоваться по умолчанию.

2. тип EBCDIC.

3. тип IMAGE.

4. тип LOCAL.


3.2. Управление форматом


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

При использовании типов данных ASCII и EBCDIC могут быть реализованы следующие режимы форматирования:

3.2. 1. Nonprint

3.2. 2. Telnet CONTROLS

3.2. 3. CARRIAGE CONTROLS ASA


По умолчанию устанавливается тип Nonprint.


3.3. Структуры данных.


Определены три типа структуры файлов.


3.3.1. Cтруктура file . Файл считается непрерывной последовательностью байтов данных. Устанавливается по умолчанию.


3.3.2. Структура record . Файл состоит из последовательных записей. Данная структура применима для типов данных ASCII и EBCDIC.


3.3.3. Структура page . Файл состоит из независимых индексированных страниц. Каждая страница должна иметь заголовок, состоящий из следующих полей:

- длина заголовка (в логических байтах) минимум 4.

- индекс страницы (идентификатор страницы в файле)

- длина данных (количество логических байт данных)

- тип страницы

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

1 - простая (длина заголовка должна быть 4)

2 - страница описателя (служит для передачи информации о файле в целом)

3 - страница контроля доступа (включает дополнительное поле заголовка для информации управления доступом. Длина заголовка - 5.


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


4. Требования к восстановлению от ошибок и рестарту


В ТС FTP может быть реализована функция рестарта.

4.1. Процедура рестарта


Процедура рестарта предоставляется для защиты клиентов от грубых ошибок системы (включая ошибки узла, процесса FTP и сети передачи данных). Процедура определена только для режимов передачи Block mode и Compressed mode. Отправитель данных периодически вставляет в поток передаваемых данных маркер рестарта с данными маркера рестарта. Принимающий узел выделяет из потока данных маркеры рестарта и отправляет их клиенту. Для выдачи клиенту сообщения о рестарте на удаленном узле должен использоваться ответ 110. В случае системной ошибки клиент может начать заново передачу данных, идентифицируя контрольную точку с помощью процедуры рестарта. Для этого посылается команда рестарта с кодом маркера в качестве аргумента.

4.2. Формат маркера рестарта


Данные маркера рестарта кодируются печатными символами алфавита, установленного по умолчанию (ASCII или EBCDIC). Маркер должен содержать информацию о счетчике битов, записей и любую другую информацию, в соответствии с контрольной точкой данных. Конкретное содержание маркера имеет значение только для передающего узла и поэтому не оговаривается.


5. Требования к структуре и составу сообщений сервера FTP и клиента FTP

5.1. Команды FTP


От клиента FTP к серверу FTP по управляющему соединению информация передается в форме команды клиента FTP.


5.1.1. Формат команд FTP


Команды FTP являются строками символов алфавита NVT-ASCII. Возможно использование другого языка. Аргументы отделяются символом <SP>. Конец определяется символом <CLRF>. Не должно делаться различия между прописными и строчными буквами как в команде, так и в аргументе.



5.1.2. Перечень команд FTP приведен в табл. 1.


Таблица 1

Перечень команд FTP


№

Команда

Сокращение

Описание

Поле аргумента

Команды управления доступом


USER NAME

USER

Имя клиента

идентификатор клиента.

PASSWORD

PASS

Пароль


пароль клиента

ACCOUNT

ACCT

Полномочия

идентификатор клиентских полномочий

Change working directory

CWD

Сменить рабочую директорию

новая рабочая директория

Change to parent directory

CDUP

Вернуться в родительскую директорию

-

Structure mount

SMNT

Смонтировать структуру

имя пути, определяющее директорию

Reinitialize

REIN

Реинициализация. (закрытие соединения данных и сброс всех установок на по умолчанию)


Logout

QUIT

Выход


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

Data port

PORT

Порт данных

h1, h2, h3, h4, p1, p2, где h1 .. h4 – адреса узла интернет, p1, p2 – адреса порта TCP.

Passive

PASV

Пассивный режим


Representation type

TYPE

Тип представления данных

A – ASCII

E – EBCDIC

I – Image

L <размер байта> - Local Byte

Для A и E определен второй параметр:

N – непечатный

T – Telnet

C – ASA


По умолч. - A N

File structure

STRU

Структура файла

F – неструктурирован

R – структ. Записей

P – структура страниц

По умолч. - F

Transfer mode

MODE

Режим передачи

S – Stream (поток)

B – Block

C – Compressed

По умолч.- S

Команды услуг FTP

Retrie ve

RETR

Пересылка от DTP сервера к DTP клиента (второго сервера)

имя файла

Store

STOR

Прием процессом DTP сервера данных и сохранение в виде файла с замещением данных в случае совпадения имени файла.

имя файла

Store Unique

STOU

Прием процессом DTP сервера данных и сохранение с генерацией уникального имени файла

имя файла

Append

APPE

Прием процессом DTP сервера данных и добавление к существующему файлу

имя файла

Allocate

ALLO

резервирование памяти

Число байт (логических)

[ R <максимальный размер записи или страницы> ]

Restart

REST

Рестарт. За этой командой должна немедленно следовать команда передачи файла.


Rename from

RNFR

Старое имя переименовываемого файла. За этой командой должна немедленно следовать команда RNTO.

старое имя файла

Rename to

RNTO

Переименование файла. Этой команде должна предшествовать команда RNFR.

новое имя файла

Abort

ABOR

Отмена предыдущей команды услуг FTP и соответствующего процесса передачи данных.


Delete

DELE

Удаление файла на сервере

имя файла

Remove directory

RMD

удаление директории (субдиректории)

имя директории

Make directory

MKD

Создание директории (субдиректории)

имя директории

Print working directory

PWD

Вызов ответа с информацией о рабочей директории


List

LIST

Вызов ответа со списком файлов в произвольном формате типа ASCII (EBCDIC) по соединению данных. Только при типе представления ASCII и EBCDIC.


[путь файла (маска)]

Name list

NLST

Вызов ответа со списком директорий в формате путей, разделенных <CRLF> или <NL> по соединению данных. Только при типе представления ASCII и EBCDIC.


[путь файла (маска)]

Site parameters

SITE

Дополнительные услуги сервера



System

SYST

Вызов ответа с типом операционной системы сервера, обозначенным в соответствии с RFC 943 [28] .


Status

STAT

Вызов ответа статуса по управляющему соединению.

[путь файла (маска)]

Help

HELP

Вызов ответа с информацией помощи по управляющему соединению

[имя команды]

Noop

NOOP

Вызов ответа сервера OK.



5.1.3. Синтаксис команд приведен в п.7.


5.1.4. Диаграммы состояний, поясняющие выполнение команд определены в п.8.


5.1.5. Обязательно должны быть реализованы команды: USER, REIN, PORT, TYPE, STRU, MODE, RETR, STOR, NOOP.


5.2. Ответы FTP


От сервера клиенту по управляющему соединению информация передается в форме ответа сервера. Ответ сервера должен следовать после каждой команды клиента.



5.2.1. Формат ответов FTP



После одной команды может быть более одного ответа. Ответ сервера может состоять из одной или нескольких строк.

Однострочный ответ состоит из:

трехзначного номера ответа, передаваемого как три символа,

символа <SP>,

текста,

символа <CRLF> .

Многострочный ответ состоит из:

трехзначного номера ответа, передаваемого как три символа,

символа "-"

текста первой строки

символа <CRLF>

текста второй строки

.....

трехзначного номера ответа, передаваемого как три символа,

символа <SP>,

текста последней строки,

символа <CRLF> .



Значения номера ответа:


первая цифра

1

Положительный предварительный ответ

2

Положительный окончательный ответ

3

Положительный промежуточный ответ

4

Временный отрицательный окончательный ответ

5

Постоянный отрицательный окончательный ответ


вторая цифра


0

Синтаксис

1

Информация

2

Соединения

3

Аутентификация и полномочия

4

Пока не определено

5

Файловая система


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

5.2.2. Список кодов ответов приведен в табл. 2. Для всех ответов, кроме 110, текст ответа не обязательно должен соответствовать приведенному в табл. 2.



Таблица 2

Список кодов ответов


Код

Текст

110

Ответ на маркер рестарта. В данном ответе текст ответа должен точно соответствовать приведенному ниже определению:

MARK <yyyy> = <mmmm>

Где yyyy - маркер потока данных от процесса клиента, а mmmm - эквивалентный маркер сервера.

Символы пробела между маркерами и символом "=" являются существенными.

120

Служба будет готова через nnn минут.

125

Соединение данных открыто. Начало передачи.

150

Статус файла - ОК. Открываю соединение данных.

200

Команда выполнена успешно.

202

Команда не реализована. Является излишней на данном узле.

211

Статус системы или ответ помощи

212

Статус директории

213

Статус файла

214

Сообщение помощи.

215

NAME < system> < type>

Имя системы имен. NAME - официальное имя системы в соответствии со списком

Assigned Numbers.

227

Вхождение в пассивный режим. (h1, h2, h3, h4, p1, p2).




230

Пользователь идентифицирован, продолжение.

250

Операция с файлом выполнено успешно.

257

"PATHNAME" создано.

220

Служба готова для нового пользователя.

221

Служба закрывает управляющее соединение.

225

Соединение данных открыто. Передача не осуществляется.

226

Закрытие соединения данных. Операция с файлом выполнена успешно.

331

Имя пользователя принято, необходим пароль.

332

Need account for login.

350

Запрошенная операция над файлом ожидает дальнейшей информации.

421

Сервис недоступен. Закрываю управляющее соединение.

425

Не могу открыть соединение данных.

426

Соединение закрыто. Передача отменена.

450

Файл недоступен.

451

Запрошенная операция отменена. локальная ошибка.

452

Запрошенная операция не принята. Недостаточно памяти.

500

Синтаксическая ошибка. Команда нераспознана.

501

Синтаксическая ошибка в аргументах.

502

Команда не реализована.

503

Неправильная последовательность команд.

504

В команде не реализован данных параметр.

530

Нет подсоединения.

532

Необходимы права на сохранение файла.

550

Запрошенная операция отменена. Файл недоступен.

551

Запрошенная операция отменена. Неизвестный тип страницы.

552

Запрошенная операция отменена. Превышен предел памяти.

553

Запрошенная операция не принята. Неправильное имя файла.



5.3. Последовательность команд и ответов


Разрешенные типы ответов сервера на команды клиента определены в табл. 3. Первыми приведены предварительные ответы (с допустимыми успешными ответами под ними), затем положительные и отрицательные окончательные ответы и в конце - промежуточные ответы с остающимися командами.














Таблица 3

Последовательность команд и ответов


Операция

Команда

Коды разрешенных ответов

Установление соединения


120



220



220



421

Login

USER

230



530



500, 501, 421



331


PASS

230



202



530



500, 501, 503, 421



332

ACCT

230



202



530



500, 501, 503, 421


CWD

250



500, 501, 502, 421, 530, 550


CDUP

200



500, 501, 502, 421, 530, 550


SMNT

202, 250



500, 501, 502, 421, 530, 550

Logout

REIN

120



220



220



421



500, 502


QUIT

221



500

Transfer parameters

PORT

200



500, 501, 421, 530


PASV

227



500, 501, 502, 421, 530


MODE

200



500, 501, 504, 421, 530


TYPE

200



500, 501, 504, 421, 530


STRU

200



500, 501, 504, 421, 530









File action commands

ALLO

200



202



500, 501, 504, 421, 530


REST

500, 501, 502, 421, 530



350


STOR

125, 150



(110)



226, 250



425, 426, 451, 551, 552



532, 450, 452, 553



500, 501, 421, 530


STOU

125, 150



(110)



226, 250



425, 426, 451, 551, 552



532, 450, 452, 553



500, 501, 421, 530


RETR

125, 150



(110)



226, 250



425, 426, 451



450, 550



500, 501, 421, 530


LIST

125, 150



226, 250



425, 426, 451



450



500, 501, 502, 421, 530


NLST

125, 150



226, 250



425, 426, 451



450



500, 501, 502, 421, 530


APPE

125, 150



(110)



226, 250



425, 426, 451, 551, 552



532, 450, 550, 452, 553



500, 501, 502, 421, 530


RNFR

450, 550



500, 501, 502, 421, 530



350

↑
Закрыть

Строительный каталог