Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 21)

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

3.2.3. Список ответов

Должны быть реализованы ответы, перечисленные в табл. 4.

Таблица 4

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

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 [ "(" full_name ") ] ) /

( full_name "")

domain ::=

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

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

TIMEZONE

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

3. Newsgroups ::= 1#Newsgroup

Newsgroup ::=

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

S ::=

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

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

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

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

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

6. Path ::=

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

7. References ::= * ( 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.

Рис. 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 клиента.

Характеристики

Список файлов стандарта