РД 45.134-2000

РУКОВОДЯЩИЙ ДОКУМЕНТ ОТРАСЛИ

Средства технические телематических служб

Общие технические требования

Предисловие

1 РАЗРАБОТАН Ассоциацией Документальной Электросвязи (АДЭ), испытательным центром документальной электросвязи (ИЦ ДЭС), испытательным центром «ЦНИИС».

ВНЕСЕН Департаментом электросвязи Министерства РФ по связи и информатизации

2 УТВЕРЖДЕН Министерством Российской Федерации по связи и информатизации 26.06.2000 г.

3 ВВЕДЕН В ДЕЙСТВИЕ информационным письмом от 14.07.2000 г. № 4316

4 ВВЕДЕН ВПЕРВЫЕ

СОГЛАСОВАНО:

Руководитель Департамента электросвязи

В.Ю. Квицинский

23.06.2000 г.

 

1. ОБЛАСТЬ ПРИМЕНЕНИЯ

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

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

Настоящие общие технические требования распространяются на технические средства следующих телематических служб:

службы обмена электронными сообщениями в части службы электронной почты (по протоколам SMTP, PОP3, IMAP4);

информационные службы в части службы доменных имен (по протоколу DNS), службы доступа к информационным ресурсам (по протоколам HTTP, NNTP, FTP).

Технические требования к техническим средствам факсимильной службы в части службы телефакс определены в РД 45.121-2000.

Технические требования к техническим средствам службы голосовой связи в части службы голосовых сообщений определены в «Общих технических требованиях на оборудование электронных речевых серверов», утвержденных Госкомсвязи России 24.06.98 г.

Технические требования к техническим средствам службы голосовой связи в части службы передачи речевых сообщений определены в РД 45.46-99.

2. НОРМАТИВНЫЕ ССЫЛКИ

3. ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

ASCII - набор символов, определенный в ARPA-Internet Protocol Handbook. В FTP определена нижняя часть восьмибитного кода (старший бит равен нулю)

ccTLD - национальный домен верхнего уровня (Country Code Top Level Domain)

CR - символ возврата каретки

CRLF - символы перехода в начало следующей строки, соответствующие <CR> и <LF>

DAP - протокол доступа к справочнику (Directory Access Protocol)

DNS - (Domain Name System) - система доменных имен

DTP (data transfer process) - процесс передачи данных. Устанавливает и управляет соединением данных. Может быть активным и пассивным.

EOF - символ конца файла, определяющий конец передаваемого файла.

EOL - последовательность символов <CR> и <LF>, разделяющая линии, выводимые на печать.

EOR - символ конца записи, определяющий конец передаваемой записи.

FTP - протокол передачи файлов (File Transport Protocol)

HTTP - протокол передачи гипертекста (Hyper Text Transfer Protocol)

IETF - Рабочая группа по инженерным проблемам сети Интернет (Internet Engineering Task Force)

IP - межсетевой протокол (Internet Protocol)

LF - символ перехода на следующую строку

MIME-IMB - формат сообщения, описанный в рекомендации RFC 2045 [8]

Mode (режим передачи данных) - определяет формат данных при передаче, включая EOR и EOF.

NNTP - Network News Transfer Protocol (протокол передачи сетевых новостей)

NUL - специальный атом, представляющий отсутствие отдельного элемента данных, представленного как строка, либо список в скобках, в отличие от пустой строки «« или пустого списка в скобках ().

NULL-строка - строка, состоящая только из символов <CRLF>

NVFS - сетевая виртуальная файловая система. Концепция, определяющая стандартную сетевую файловую систему со стандартными командами и преобразованием имен путей.

NVT - виртуальный терминал сети, согласно определению, данному в описании протокола Telnet.

Page (страница) - структурная единица файла.

Pathname - символьная строка, идентифицирующая файл в файловой системе. Конкретный вид зависит от файловой системы.

PI - интерпретатор протокола. Стороны клиента и сервера реализуют PI клиента и PI сервера.

РОР3 - протокол обмена почтовой информацией (Post Office Protocol)

RADIUS - протокол аутентификации пользователей в соответствии с RFC 2138 [29] (Remote Authentication Dial In User Service)

Record (запись) - структурная единица последовательного файла. Структура записей поддерживается FTP, но файл не должен состоять из структуры записей.

RFC - обозначение документа IETF (Request For Comments)

RR (Resource Records) - набор информации о ресурсе, связанный с отдельным доменным именем

SMTP - простой протокол передачи почты (Simple Mail Transport Protocol)

SNMP - протокол управления сетью на базе ТСР/IР (Simple Network Management Protocol)

SP - символ пробела

TCP - транспортный протокол (Transport Control Protocol)

TCP/IP - стек протоколов межсетевого взаимодействия (Transmission Control Protocol/Internet Protocol)

Type (тип представления данных). Тип определяет преобразования при хранении данных и передаче данных.

UDP (User Datagramm Protocol) - протокол пользовательских датаграмм

UID - уникальный идентификатор почтового сообщения

URI - Universal Resource Identifier (универсальный идентификатор ресурса)

URL - Uniform Resource Locators (унифицированный указатель ресурсов)

АВ-терминал - аудио-видео терминал

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

Авторитетный сервер - сервер, хранящий полную информацию о зоне

Агент клиентский - клиент, инициирующий запрос (броузер, редактор, робот или другое средство)

Адресат - клиент, которому предназначается почтовое сообщение

АП - агент пользователя

АПС - агент передачи сообщений

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

Валидатор - элемент протокола, используемый для определения, является ли данная позиция кэша эквивалентной копией сущности.

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

Возраст - время, прошедшее с момента отправки или успешной проверки актуальности ответа.

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

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

Данные электронной почты - последовательность произвольной длины, состоящая из символов кода ASCII, удовлетворяющая формату почтового сообщения в соответствии с RFC 822 [2].

Домен - иерархически структурированный глобальный адрес компьютера узла сети в виде строки символов

Заголовок сообщения HTTP - 1. набор строк между первой строкой сообщения (start-line) и пустой строкой, отделяющей заголовок от тела сообщения. 2. - строка (несколько строк), содержащая выражение, задающее значение для отдельного поля заголовка сообщения.

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

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

ИС - информационная служба

ИСО - Международная организация по стандартизации (International Organization for Standartization)

Канал передачи - полнодуплексное соединение между передатчиком SMTP и приемником SMTP, используемое для обмена командами, ответами и текстом почтовых сообщений.

«Клеевые» записи - записи, содержащие ссылку на авторитетный сервер подзоны

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

Команда - сообщение NNTP, направляемое от клиента к серверу

Конверт сообщения - заголовок почтового сообщения.

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

«Лист» - элемент иерархического графа, дерева, не имеющего выходящих дуг

Литерал - основная форма строки. Представляет последовательность из 0 или более октетов (включая символы <CR> и <LF>), которой предшествует счетчик октетов. Формат счетчика октетов: открывающаяся фигурная скобка «{«, число октетов, закрывающаяся фигурная скобка «}», <CRLF>. В случае, когда литерал посылается от клиента серверу, клиент должен ждать получения запроса продолжения команды перед отправлением данных (и остатка команды). Даже если счетчик октетов равен 0, клиент, передающий буквенную строку, должен ждать получения команды запроса продолжения.

МПС - служба межперсональных сообщений

МСЭ - Международный союз электросвязи

МСЭ-Т - Сектор стандартизации электросвязи МСЭ

Новости электронные (news) - вид информации, периодически распространяемой в виде электронных сообщений большому количеству клиентов по сети передачи данных.

Номер порядковый почтового сообщения - относительный номер сообщения в почтовом ящике. Сообщения в почтовом ящике должны располагаться по возрастанию значения UID. Два соседних порядковых номера сообщения должны отличаться точно на 1. Порядковые номера сообщений могут изменяться в течение сессии.

Остаток (имени, команды) - последний элемент (группа элементов) структуры

Ответ - сообщение NNTP, направляемое от сервера клиенту

Ответ актуальный - ответ, который не устарел, не утратил актуальности

Ответ отрицательный - ответ со значением индикатора статуса «-ERR»

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

Ответ положительный - ответ со значением индикатора статуса «+OK»

Ответ устаревший - ответ, у которого истек срок его актуальности

Отправитель - клиент, инициировавший отправку почтового сообщения

Передатчик SMTP - процесс, осуществляющий передачу электронной почты. Передатчик SMTP инициирует соединение транспортного уровня.

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

Приемник SMTP - процесс, осуществляющий прием электронной почты.

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

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

«Разрез» - точка разделения иерархического графа (дерева) на два составляющих иерархических графа (поддерева)

РД - руководящий документ

Режим стойких соединений - режим работы сервера, при котором он обрабатывает несколько запросов клиента, не разрывая соединения TCP с данным клиентом.

Ресурс - объект сетевых данных или служба, которая может быть идентифицирована посредством URI.

САК - служба аудиоконференций

СВК - служба видеоконференций

СГС - служба голосовых сообщений

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

Сервер-источник - сервер, на котором находится или создается данный ресурс.

Сессия - набор процедур обмена, происходящих по открытому соединению транспортного уровня

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

СКА - сервер контроля и авторизации

Слово - последовательность печатных символов

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

Соединение данных - полнодуплексное соединение, по которому в определенном режиме (mode) передаются данные определенного типа (type).

Сообщение - информация, состоящая из структурированной последовательности октетов, удовлетворяющая синтаксису сообщения HTTP и передаваемая по соединению

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

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

Список рассылки (mailing list) - способ организации доставки электронных новостей, а также набор аппаратно-программного обеспечения, реализующего данный способ. При данном способе доставки электронные новости доставляются клиенту средствами электронной почты в моменты времени, определяемые серверной стороной списка рассылки.

СПРИ - служба передачи речевой информации

СПС - система передачи сообщений

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

Срок истечения точный - время, по истечении которого сервер-источник считает, что сущность не должна больше выдаваться кэшем без дальнейшей проверки актуальности.

Срок истечения эвристический - срок истечения точный, устанавливаемый кэшем.

Статья - сообщение электронных новостей

СТК - служба телеконференций

Строка бинарная - это любая строка с символами NUL.

Строка в кавычках - форма строки, представляющая собой последовательность из 0 или более семибитных символов, кроме символов <CR> и <LF>, с символом двойной кавычки <«> с каждой стороны.

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

СХИ - система хранения информации

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

ТМ службы - телематические службы

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

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

ТС - сеанс телеконференцсвязи

ТфОП - телефонная (сеть) общего пользования

Узел сети (узел) - компьютер, подключенный к сети, на котором запущен процесс SMTP, либо присутствуют почтовые ящики

Указатель конца данных почты - специальная последовательность символов, указывающая на конец данных электронной почты. Состоит из последовательности символов: CR, LF, символа точка («.»), CR, LF.

УПОР - устройство пакетной обработки речи

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

УТС DNS - узел телематических служб, реализующий функции сервера DNS.

УТС FTP - узел телематических служб, реализующий функции сервера FTP.

УФС - узел факсимильной связи

ХС - хранилище сообщений

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

ЭП - электронная почта

Ящик электронной почты (почтовый ящик) - набор символов, идентифицирующий клиента, которому отправляется почта. Обычно состоит из спецификации клиента и узла. Дополнительно, под данным термином понимают абстрактный «контейнер», в котором хранятся сообщения электронной почты.

4. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

Технические требования к техническим средствам службы обмена электронными сообщениями в части службы электронной почты по протоколу SMTP приведены в Приложении 1.

Технические требования к техническим средствам службы обмена электронными сообщениями в части службы электронной почты по протоколу РОР3 приведены в Приложении 2.

Технические требования к техническим средствам службы обмена электронными сообщениями в части службы электронной почты по протоколу IMAP4 приведены в Приложении 3.

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

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

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

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

5. ТРЕБОВАНИЯ К ТЕХНИЧЕСКОМУ ОБЕСПЕЧЕНИЮ

Используемые при создании ТС телематической службы средства вычислительной техники должны иметь сертификаты системы ГОСТ Р, подтверждающие соответствие Российским стандартам на средства вычислительной техники, эксплуатируемые в производственных помещениях.

6. ТРЕБОВАНИЯ К НАДЕЖНОСТИ И ДОСТОВЕРНОСТИ

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

7. ТРЕБОВАНИЯ К ДИАГНОСТИКЕ

Диагностика аппаратной части и системного программного обеспечения ТС телематических служб должна производиться средствами, поставляемыми предприятиями - изготовителями средств вычислительной техники и программного обеспечения. Указанные средства должны включать тестовое ПО комплекса технических средств телематических служб, обеспечивающее проверку работоспособности ТС телематических служб и диагностику.

Средства диагностики сервера (узла) телематических служб не должны нарушать целостность и корректность данных.

8. ТРЕБОВАНИЯ К ЭЛЕКТРОПИТАНИЮ

Система должна быть работоспособной при электропитании оборудования системы от источников бесперебойного электропитания, обеспечивающих на выходе напряжение 220 В с частотой 50 Гц и допустимыми отклонениями напряжения от минус 15 % до +10 % и частоты ±5 Гц.

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

9. ТРЕБОВАНИЯ К ЭЛЕКТРОБЕЗОПАСНОСТИ И ЭЛЕКТРОМАГНИТНОЙ СОВМЕСТИМОСТИ

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

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

10. ТРЕБОВАНИЯ ПО УСТОЙЧИВОСТИ К КЛИМАТИЧЕСКИМ ФАКТОРАМ

ТС телематических служб должен оставаться работоспособным при температуре окружающего воздуха от 5 до 40 °С и относительной влажности от 20 до 80 % (без конденсата).

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

11. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ

В состав документации на ТС телематических служб должны входить следующие обязательные документы:

Технические условия;

Комплект эксплуатационной документации.

Технические условия на ТС телематических служб должны быть выполнены на русском языке и соответствовать требованиям настоящих ОТТ.

Комплект эксплуатационной документации должен быть выполнен на русском языке и должен содержать:

- общее описание, включая контрольный пример;

- руководства администратора и оператора.

ПРИЛОЖЕНИЕ 1

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ СРЕДСТВАМ СЛУЖБЫ
ЭЛЕКТРОННОЙ ПОЧТЫ ПО протоколу SMTP

1. ОБЛАСТЬ ПРИМЕНЕНИЯ

Настоящее приложение описывает технические требования к ТС службы ЭП по протоколу SMTP в соответствии с RFC 821 [1].

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

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

2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К SMTP

2.1. Соединения

2.1.1. Протокол нижнего уровня

При использовании TCP для организации соединения клиента и сервера должен использоваться порт 25. При кодировании сообщений SMTP должно учитываться, что соединение TCP поддерживает длину байта 8 бит. Семибитные символы сообщений SMTP должны быть выровнены вправо, а старший бит октета установлен в 0.

2.1.2. Установление соединений.

В результате запроса клиента передатчик SMTP устанавливает дуплексное соединение с приемником SMTP.

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

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

2.2. Взаимодействие

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

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

Первой командой в сессии должна быть команда HELO. Последней командой сессии должна быть команда QUIT. Элементы взаимодействия по протоколу SMTP приведены в п. 8.

3. СООБЩЕНИЯ

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

Команды и ответы состоят из символов кода ASCII.

3.1. Команды

Командами являются символьные строки, заканчивающиеся <CRLF>. Команды состоят из кода команды и последующего поля аргументов. Коды команды и аргументы должны быть разделены одним или более пробелами. Регистр символов кода команды и названий параметров, таких как «to:» или «from:», не является существенным. Регистр аргументов прямого и обратного пути является существенным. Поле аргумента состоит из строки символов переменной длины, заканчивающееся <CRLF>.

3.1.1. Перечень команд

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

Таблица 1

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

 

 

 

 

 

 

 

 

 

 

 

 

 

3.1.2. Синтаксис команд определен в п. 5.

3.1.3. Команды: НЕLO, MAIL, RCPT, DATA, RSET, NOOP, QUIT должны быть реализованы обязательно.

3.1.4. Обеспечение прозрачности передачи данных в команде DATA

При посылке передатчиком данных почты каждую последовательность «<CRLF>.» (0x0D 0х0А 0х2Е) передатчик должен заменять на «<CRLF>..» (0x0D 0х0А 0х2Е 0х2Е). Приемник должен выполнять обратное преобразование. Указатель конца почтовых данных этому преобразованию не подвергается.

3.2. Ответы

3.2.1. Код ответа

Ответ SMTP состоит из трехзначного кода ответа (передаваемого как три символа), за которым следует текст.

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

первая цифра

вторая цифра

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

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

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

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

символа <SP>,

текста,

символа <CRLF>.

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

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

символа «-»

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

символа <CRLF>

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

символа «-»

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

символа <CRLF>

+...

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

символа <SP>,

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

символа <CRLF>.

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

Таблица 2

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

3.3. Порядок команд и ответов

Первой командой в сессии должна быть команда HELO. Если аргумент команды HELO является неприемлемым, должен быть выдан ответ 501 и приемник SMTP должен остаться в прежнем состоянии.

Команды NOOP, HELP, EXPN, VRFY могут использоваться в любое время в течение сессии.

Команды MAIL, SEND, SOML, SAML начинают транзакцию. Если аргумент команды начала транзакции является неприемлемым, приемник должен выдать ответ 501 и остаться в прежнем состоянии. Во время транзакции должны использоваться команды в следующей последовательности: одна или несколько команд RCPT, одна команда DATA. Транзакция может быть прервана командой RSET. В течение сессии может быть 0, 1 или более транзакций. Если во время транзакции команды выдаются с нарушением указанного порядка, приемник должен выдать ответ 503 и остаться в прежнем состоянии.

Последней командой сессии должна быть команда QUIT. Команда QUIT может быть выдана в любое время в течение сессии.

На каждую команду должен выдаваться точно один ответ.

В п. 6 и п. 7 определяются допустимые последовательности команд и ответов.

3.4. Ограничения на размер элементов сообщений SMTP

Ограничения на размер элементов сообщений SMTP приведены в табл. 3

Таблица 3

Ограничения на размер элементов сообщений SMTP

4. ОПИСАНИЕ СИНТАКСИСА КОМАНД И ОТВЕТОВ

Примечание 1: символ «\» указывает на то, что следующий за ним специальный символ интерпретируется «буквально», а не в соответствии с обычной интерпретацией.

Примечание 2: для именования узлов используются две дополнительные числовые формы. Первая форма состоит из символа «#», за которым следует целое десятичное число, являющееся адресом узла. Вторая форма состоит из 4-х целых десятичных чисел, разделенных точками и заключенных в квадратные скобки. Вторая форма соответствует адресу IP.

5. ПОСЛЕДОВАТЕЛЬНОСТЬ КОМАНД И ОТВЕТОВ

Используются следующие сокращения:

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

S - успешное выполнение

F - неудача

Е - ошибка

6. ДИАГРАММЫ СОСТОЯНИЙ СЕРВЕРА SMTP

Диаграмма состояний сервера SMTP для команд HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, NOOP, QUIT, TURN приведены на рис. 1. Диаграмма состояний сервера SMTP для команды DATA приведена на рис. 2.

Рис. 1 Диаграмма состояний сервера SMTP для команд HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, NOOP, QUIT, TURN

Рис. 2 Диаграмма состояний сервера SMTP для команды DATA

Используемые сокращения на рис. 1 и рис. 2:

В - Начало

S - Успешное выполнение

F - Неудача

Е - Ошибка

W - Ожидание ответа

data - серия линий с данными почты, посылаемых от передатчика приемнику.

М - Среднее состояние

Цифрами обозначены возможные номера ответов, что соответствует первой цифре трехзначного кода ответа, как это описано в пункте 4.2.1.

7. ОПИСАНИЕ ПРОЦЕДУР SMTP

На рис. 3. показана схема соединений при взаимодействии SMTP.

Рис. 3. Схема соединений при взаимодействии SMTP

Рассматривают следующие процедуры SMTP во время взаимодействия SMTP:

- транзакция,

- направление,

- верификация,

- доставка в почтовый ящик,

- доставка на терминал клиента,

- открытие и закрытие соединения

7.1. Открытие и закрытие соединения

Для открытия соединения используется команда HELO. Этой командой идентифицируется узел передатчика SMTP.

HELO <домен>

Для закрытия соединения используется команда: QUIT

Во время соединения приемник и передатчик могут поменяться ролями. Для этого используется команда TURN. Инициатором обмена ролями должен быть передатчик. Для отказа обмена используется ответ 502. Данная команда не должна использоваться в случае, если в качестве протокола транспортного уровня используется TCP.

7.2. Транзакция

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

Сразу после установления соединения передатчик SMTP посылает команду MAIL, указывающую отправителя почты. Если приемник SMTP может принять почту, он отвечает OK. После этого передатчик SMTP посылает команду RCPT, указывающую получателя почты. Если приемник SMTP может принять почту для данного получателя, он отвечает OK. Если нет, он высылает ответ, отклоняющий данного получателя (но не всю транзакцию). Передатчик SMTP и приемник SMTP могут согласовать нескольких получателей. После завершения согласования получателей, передатчик SMTP отправляет данные почты, заканчивающиеся определенной последовательностью. Если приемник SMTP успешно обработал полученные данные, он отвечает OK.

Таким образом транзакция состоит из трех шагов, что отображено на табл. 4.

Таблица 4

Шаги транзакции

Пример процедуры Транзакция:

S: MAIL FROM:<Smith@Alpha.ARPA>

R: 250 OK

S: RCPT TO:<Jones@Beta.ARPA>

R: 250 OK

S: RCPT TO:<Green@Beta.ARPA>

R: 550 No such user here

S: RCPT TO:<Brown@Beta.ARPA>

R: 250 OK

S: DATA

R: 354 Start mail input; end with <CRLF>.<CRLF>

S: Blah blah blah...

S: ...etc. etc. etc.

S: <CRLF>. <CRLF>

R: 250 OK

7.3. Направление

В случаях, когда информация аргумента <прямой путь> команды RCPT оказывается некорректной, но приемник SMTP знает адресат, должны использоваться следующие ответы:

251 Клиент не локальный. Сообщение переслано в <прямой путь>

551 Клиент не локальный. Попробуйте <прямой путь>

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

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

7.4. Верификация

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

По команде VRFY приемник по введенному имени клиента выдает полное имя клиента и имя его почтового ящика.

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

7.5. Доставка в почтовый ящик и доставка на терминал клиента

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

SEND from:<обратный путь>

Если адресат неактивен или не принимает почтовое сообщение, отправитель получит ответ 450.

Команда SOML позволяет доставить почту на терминал клиента, если он активен и принимает сообщения, или оставить в почтовом ящике, в противном случае. Команда SAML позволяет доставить почту на терминал клиента (если он активен) и поместить ее в почтовый ящик.

7.6. Пересылка

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

Если сервер SMTP взял на себя задачу пересылки почты и позднее обнаружил, что почта по какой-либо причине не может быть доставлена, он должен составить извещение о невозможности доставить почту и выслать его отправителю. Сервер SMTP не должен высылать извещения о проблемах пересылки извещений. Для этого при отправке извещения используется команда с нулевым обратным путем.

ПРИЛОЖЕНИЕ 2

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ СРЕДСТВАМ СЛУЖБЫ
ЭЛЕКТРОННОЙ ПОЧТЫ ПО ПРОТОКОЛУ РОР3

1. ОБЛАСТЬ ПРИМЕНЕНИЯ

Настоящее приложение описывает технические требования к ТС службы ЭП по протоколу РОР3 в соответствии с RFC 1939 [3] и RFC 1734 [4].

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

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

2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К ВЗАИМОДЕЙСТВИЮ КЛИЕНТА РОР3 И СЕРВЕРА РОР3

2.1. Соединения

2.1.1. Протокол нижнего уровня

Для организации соединения клиента и сервера должен использоваться протокол TCP. На стороне сервера должен использоваться порт 110.

2.1.2. Общая структура протокола

Сессия протокола РОР3 состоит из установления соединения клиент/сервер, начального приветствия от сервера и взаимодействия клиент/сервер. В ходе сессии сервер и клиент обмениваются сообщениями. Сообщения разделяются на команды клиента и ответы сервера. В ответы сервера включаются данные, передаваемые сервером клиенту и результаты выполнения команд. Все сообщения передаются клиентом и сервером в форме строк, заканчивающимися символом <CRLF>.

2.2. Взаимодействие

2.2.1. Состояния сервера

В сервере должны быть реализованы следующие состояния:

AUTHORIZATION

TRANSACTION

UPDATE

Типичная последовательность переходов состояний сервера показана на рис. 1.

Рис. 1 Типичная последовательность состояния сервера

2.2.1.1. Сервер должен находиться в состоянии AUTHORIZATION после установления соединения TCP и выдачи им ответа приветствия.

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

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

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

В состоянии AUTHORIZATION должны быть реализованы команды как минимум одного из механизмов идентификации, приведенных в п. 3.3.2., и команда QUIT.

2.2.1.2. Состояние TRANSACTION

Сервер переходит в состояние TRANSACTION в случае успешной идентификации клиента и успешного открытия почтового ящика.

Если сервер получает команду QUIT, он должен перейти в состояние UPDATE. В состоянии TRANSACTION должны быть реализованы следующие команды: STAT, LIST, RETR, DELE, NOOP, RSET, QUIT.

2.2.1.3. Состояние UPDATE

Сервер переходит в состояние UPDATE в случае получения команды QUIT в состоянии TRANSACTION. В состоянии UPDATE (и только в этом состоянии) сервер удаляет из почтового ящика сообщения, помеченные как удаленные.

2.2.2. Механизмы идентификации клиента

В сервере могут быть реализованы следующие механизмы идентификации клиента:

с помощью команд USER и PASS

с помощью команды АРОР

с помощью команды AUTH (дополнительный механизм идентификации)

2.2.2.1. На сервере должен быть реализован механизм идентификации с помощью команд USER и PASS. Команда PASS должна следовать непосредственно за командой USER. Формат команд USER и PASS описан в п. 4.1 настоящего Руководящего Документа.

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

Клиент должен запомнить последнюю присланную ему метку времени и использовать ее в команде АРОР.

Формат команды АРОР: АРОР <name> <digest>

Более подробно формат команды описан в п. 4.1. настоящего Руководящего Документа.

Значение параметра name такое же, как в команде NAME. Параметр digest должен вычисляться согласно алгоритму MD5 в соответствии с RFC 1321 [5], применяемому к метке времени и следующей за ней строке пароля. Параметр digest должен иметь формат 16-октетного числа в 16-ричном формате, представленного в ASCII-коде, используя строчные буквы.

Получая команду АРОР, сервер должен проверить соответствие параметра digest. В случае соответствия выдается положительный ответ, и сервер переходит в состояние TRANSACTION. В случае несоответствия сервер выдает отрицательный ответ и остается в состоянии AUTHORIZATION.

2.2.2.3. Механизм идентификации с помощью команды AUTH.

Механизмы идентификации и защиты, используемые командой AUTH в протоколе РОР3, должны быть аналогичны используемым в протоколе IMAP4 и соответствовать RFC 1731 [6], 1734 [4].

Формат команды AUTH описан в п. 4.1. настоящего Руководящего Документа. Команда передает серверу параметр с указанием, какой механизм идентификации должен быть использован. Если в сервере поддерживается запрошенный механизм, сервер производит обмен сообщениями с клиентом для идентификации пользователя. Также может быть выполнено согласование механизма защиты для последующих сессий.

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

Обмен сообщениями протокола идентификации состоит из серий вызовов, исходящих от сервера, и ответов клиента, являющихся специфичными для каждого механизма идентификации. В качестве вызова сервера используется ответ «готов». Вызов сервера должен иметь формат строки в коде BASE64 с первым символом «+». Ответ клиента должен иметь формат строки в коде BASE64. Ответ клиента «*» вызывает прерывание процедуры идентификации и последующий отрицательный ответ сервера. Если установлен механизм защиты, он применяется ко всем последующим пересылкам данных по соединению. Механизм защиты должен активизироваться сразу после получения символа <CRLF> положительного ответа сервера после обмена сообщениями протокола идентификации. При активном механизме защиты потоки символов команд и ответов преобразуются в зашифрованные буферы. Каждый буфер передается как поток октетов, которому предшествует 4-октетное поле длины последующих данных. Максимальная длина шифрованного буфера определяется механизмом защиты.

2.2.3. В сервере может быть реализован таймер разъединения по отсутствию активности. Установленное время таймера разъединения по отсутствию активности должно быть как минимум 10 минут. Получение любой команды должно сбрасывать таймер. При закрытии сессии по отсутствию активности сервер:

- не должен входить в состояние UPDATE,

- не должен удалять сообщения,

- не должен посылать ответ клиенту.

3. ПЕРЕЧЕНЬ И СТРУКТУРА СООБЩЕНИЙ

Все сообщения протокола РОР3 должны быть стандартными текстовыми сообщениями в соответствии с RFC822 [2].

3.1. Команды

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

3.1.1. Структура команд

Команды состоят из печатных символов кода ASCII. Структура команды:

ключевое слово

один или более аргументов (могут отсутствовать)

символ <CRLF>

Ключевое слово и аргументы, а также аргументы между собой разделяются одним символом <SP> (пробел).

Максимальная длина аргумента составляет 40 символов.

Длина ключевого слова составляет 3 или 4 символа.

3.1.2. Перечень команд

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

Таблица 1

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

 

 

 

 

 

 

 

 

 

 

 

3.1.3. Обязательными для реализации являются команды: QUIT, STAT, LIST, RETR, DELE, NOOP, RSET, USER, PASS.

3.2. Ответы

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

3.2.1. Формат ответа

Ответы состоят из отображаемых символов кода ASCII. Каждый ответ заканчивается символом <CRLF>. Максимальная длина ответа, включая символы <CRLF>, составляет 512 символов.

Ответ состоит из индикатора статуса и последующего текста ответа. Индикатор статуса может принимать значения либо «+OK» либо «-ERR». Буквы в индикаторе статуса должны быть заглавными. Ответы с индикатором статуса «+OK» называются положительными, ответы с индикатором статуса «-ERR» называются отрицательными.

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

Ответы могут быть однострочными и многострочными. В многострочных ответах строки отделяются символами <CRLF>. Последняя строка многострочного ответа состоит из заключительного октета (с десятичным кодом 46 («.»)) и символов <CRLF>. Если строка многострочного ответа начинается с символа «,», в начало этой строки добавляется еще один символ «.». Таким образом критерием конца многострочного ответа является последовательность «CRLF.CRLF». Оконечная последовательность «.CLRF» не считается частью многострочного ответа.

На нереализованные или нераспознанные команды сервер должен отвечать отрицательным ответом. На команды, не разрешенные в данном состоянии, сервер должен отвечать отрицательным ответом.

3.2.2. Список ответов с фиксированной структурой текста ответа.

Список ответов с фиксированной структурой текста ответа приведен в табл. 2.

Таблица 2

Список ответов с фиксированной структурой текста ответа

 

 

 

 

 

 

4. СИНТАКСИС КОМАНД И ОТВЕТОВ

В приведенном ниже определении синтаксиса команд и ответов сервера РОР3 используется расширенная форма Наура-Бекуса, приведенная в рекомендации RFC 822 [2]. Замечание: в качестве разделителя в конструкции «#» используется один пробел и не используются запятые. В случае противоречия в приведенных определениях должно использоваться правило, указанное выше по списку. Различие между строчными и прописными символами алфавита является несущественным.

5. ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ СЕРВЕРА

5.1. Механизм ограничения объема хранящихся сообщений

В сервере может быть реализован механизм ограничения объема хранящихся сообщений.

5.2. Механизм удаления сообщений, хранящихся дольше установленного срока

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

ПРИЛОЖЕНИЕ 3

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ СРЕДСТВАМ СЛУЖБЫ
ЭЛЕКТРОННОЙ ПОЧТЫ ПО ПРОТОКОЛУ IMAP4

1. ОБЛАСТЬ ПРИМЕНЕНИЯ

Настоящее приложение описывает технические требования к ТС службы ЭП по протоколу IMAP4 в соответствии с RFC 822 [2], RFC 1733 [7] и RFC 2045 [8].

В приложении приведены операции создания, удаления и переименования почтовых ящиков, проверки на наличие новых сообщений, удаления сообщений после прочтения, установки и снятия флагов, разбора сообщений в соответствии со стандартами RFC 822 [2] и RFC 2045 [8], поиска, избирательной выдачи атрибутов и текста сообщений, а также их частей. Доступ к сообщениям организован с использованием либо последовательных номеров сообщений (относительная позиция сообщения в почтовом ящике), либо уникальных идентификаторов (постоянных, последовательно увеличивающихся значений, выделяемых для каждого сообщения).

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

2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К ВЗАИМОДЕЙСТВИЮ КЛИЕНТА IMAP4 И СЕРВЕРА IMAP4

2.1. Соединения

2.1.1. Протокол нижнего уровня

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

2.1.2. Общая структура протокола

Сессия протокола IMAP4 состоит из установления соединения клиент/сервер, начального приветствия от сервера и взаимодействия клиент/сервер. В ходе сессии сервер и клиент обмениваются сообщениями. Сообщения разделяются на команды клиента и ответы сервера. В ответы сервера включаются данные, передаваемые сервером клиенту, и результаты выполнения команд. Все сообщения передаются клиентом и сервером в форме строк, заканчивающихся символами <CRLF>.

2.1.3. Соответствие команд и ответов

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

В ответах без тега вместо тега должен следовать символ «*» или символ «+».

2.2. Состояния

Сервер может находиться в одном из 4-х состояний:

Non-Authenticated («не идентифицирован»);

Authenticated («идентифицирован»);

Selected («выбран»);

Logout («разъединение»).

Для каждого состояния существует свой набор разрешенных команд. На запрещенную команду сервер должен выдавать ответ результата выполнения команды BAD или NО. Диаграмма типовых переходов состояний приведена на рис. 1.

Рисунок 1. Диаграмма типовых переходов состояний

На рис. 1 цифрами обозначены: 1 - соединение без преидентификации (приветствие OK), 2 - соединение с преидентификацией (приветствие PREAUTH), 3 - отвергнутое соединение (приветствие BYE), 4 - успешное выполнение команды LOGIN или AUTHENTICATE, 5 - успешное выполнение команды SELECT или EXAMINE, 6 - команда CLOSE или неудачное выполнение команд SELECT или EXAMINE, 7 - команда LOGOUT, сервер закрыт или соединение закрыто.

2.2.1. Состояние «не идентифицирован»

Сервер входит в состояние «не идентифицирован» после установления соединения, если только соединение не является преидентифицированным.

2.2.2. Состояние «идентифицирован»

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

2.2.3. Состояние «выбран»

Сервер входит в это состояние после того, как почтовый ящик успешно выбран.

2.2.4. Состояние «отсоединено»

В состоянии «отсоединено» идет процесс завершения соединения, после чего сервер закрывает соединение. Сервер может перейти в данное состояние по запросу клиента или по внутреннему одностороннему решению сервера.

2.3. Элементы функционирования сервера

2.3.1. Наименование почтовых ящиков

Имя почтового ящика INBOХ является специальным именем, зарезервированным для «первичного почтового ящика данного пользователя на данном сервере».

2.3.2. Иерархическое именование почтовых ящиков

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

2.3.3. Размер почтового ящика и обновления статуса сообщений.

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

2.3.4. Ответы при отсутствии выполняемых в данное время команд.

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

2.3.5. Таймер автоотсоединения

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

2.3.6. Выполнение нескольких команд

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

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

2.3.7. Идентификация

Команды AUTHENTICATE и LOGIN запускают процесс идентификации в состоянии Non-authenticated. В сервере может быть реализован неидентифицированный доступ к определенным почтовым ящикам. Для этого должна использоваться команда LOGIN с идентификатором пользователя «anonimus». Наличие пароля является необходимым.

2.3.8. Атрибуты почтового ящика

Должны быть реализованы следующие атрибуты почтового ящика:

\Noinferiors - порожденные уровни не существуют и не могут быть созданы;

\Noselect - невозможно использовать данное имя в качестве выбираемого почтового ящика;

\Marked - почтовый ящик отмечен сервером, как почтовый ящик, в который были добавлены новые сообщения;

\Unmarked - после того, как почтовый ящик был выбран последний раз, в него не были добавлены новые сообщения.

3. ПЕРЕЧЕНЬ И СТРУКТУРА СООБЩЕНИЙ ПРОТOKОЛА IMAP4

3.1. Форматы данных, используемые в сообщениях

Протокол IMAP4 использует текстовые команды и ответы. Данные могут быть представлены в одной из 5 форм:

атом;

число;

строка;

список в скобках;

NIL.

Формальное определение форматов данных приведено в Приложении 5.2.

3.1.1. Строки.

Должны быть реализованы два вида строки: литерал и строка в кавычках.

3.1.2. Восьмибитные и бинарные строки.

Восьмибитная текстовая и бинарная почта поддерживается с помощью кодирования MIME-IMB (RFC 2045 [8]). Возможно использование литералов для передачи восьмибитовых или многооктетных символов, но только тогда, когда определен набор символов CHARSET (RFC 1700 [9]).

Несмотря на существование кодирования BINARY для тела сообщения, некодированные бинарные строки запрещены.

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

3.2. Атрибуты почтовых сообщений

3.2.1. Уникальный номер почтового сообщения (UID), порядковый номер почтового сообщения и идентификатор валидности.

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

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

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

3.2.2. Флаги почтового сообщения

Должны быть реализованы флаги:

\Seen

\Answered

\Flagged

\Deleted

\Draft

\Recent

Могут быть реализованы дополнительные флаги.

3.3. Команды

Сообщения, направляемые от клиента серверу, называются командами. Формат команд приведен в п. 5. Список команд с описанием назначения приведен в табл. 1.

Таблица 1

Список команд

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3.4. Ответы

Сообщения, направляемые от сервера клиенту, называются ответами. Существуют три формы ответов сервера:

ответы статуса

данные сервера

запрос продолжения команды

Ответы статуса могут быть:

с тегом

без тега

Ответы с тегом показывают результат выполнения команды клиента: статус OK, NO, BAD.

В ответе без тега на месте тега находится символ «*». Ответами статуса без тега могут быть ответ приветствия или ответы статуса, не показывающие результаты выполнения какой-либо команды.

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

3.4.1. Ответы статуса

Ответами статуса являются: OK, BAD, NO, PREAUTH, BYE.

Ответы OK, BAD, NO могут быть с тегом и без тега.

Ответы PREAUTH и BYE всегда с тегом.

Ответы статуса могут включать код ответа. Код ответа состоит из данных внутри квадратных скобок в форме атома. Возможны аргументы, отделенные пробелом. Список кодов ответа приведен в табл. 2. Все дополнительные коды ответов, реализованные в сервере, должны начинаться с буквы X.

Таблица 2

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

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

Таблица 3

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

3.4.2. Ответы статуса сервера и почтового ящика

С помощью данных ответов сервер передает данные клиенту. В табл. 4 приведен список ответов статуса сервера и почтового ящика.

Таблица 4

Список ответов статуса сервера и почтового ящика

3.4.3. Ответы размера почтового ящика

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

Таблица 5

Список ответов размера почтового ящика

3.4.4. Ответы статуса сообщений

С помощью данных ответов сервер передает клиенту данные сообщений. В табл. 6 приведен список ответов статуса сообщений. Сразу за символом «*» находится последовательный номер сообщения.

3.4.5. Ответ запроса продолжения команды

Данный ответ показывает, что сервер готов принять продолжение команды от клиента. Данный ответ используется в команде AUTHORIZATION для выполнения передачи данных сервера клиенту и запроса дополнительных данных клиента. Данный ответ может также использоваться для любой команды в случае, если аргументом является литерал. Клиент не должен высылать октеты текста литерала, пока сервер не выдаст запрос. Остаток команды, включая <CRLF>, следует за октетами литерала. В случае, если присутствуют дополнительные аргументы, за литералом должен следовать пробел и эти аргументы.

Таблица 6

Список ответов статуса сообщений

4. СИНТАКСИС КОМАНД И ОТВЕТОВ

В приведенном ниже определении синтаксиса команд и ответов сервера IMAP4 используется расширенная форма Наура-Бекуса, приведенная в рекомендации RFC 822 [2].

Замечание: в качестве разделителя в конструкции «#» используется один пробел и не используются запятые. В случае противоречия в приведенных определениях должно использоваться правило, указанное выше по списку. Различие между строчными и прописными символами алфавита является несущественным.

 

 

5. СТРУКТУРА ПОЧТОВОГО СООБЩЕНИЯ В СООТВЕТСТВИИ С RFC 822

Сообщение состоит из заголовка и необязательного тела сообщения. Тело сообщения является простым набором линий, содержащих символы ASCII. Тело сообщения отделено от заголовка NULL-строкой (строкой, состоящей только из символов <CRLF>). Заголовок сообщения состоит из полей заголовка. Каждое поле состоит из имени поля, двоеточия - символа «:» и значения поля. Значение поля может быть разбито на части символами <CRLF>. При этом символы <CRLF> должны немедленно следовать за символом <LWSP>. Далее поля заголовка описываются в предположении, что из их значений выброшены символы <CRLF>.

Приведено определение структуры сообщения с использованием формы Наура-Бекуса. В определениях используются элементы, определенные в п. 5.

ПРИЛОЖЕНИЕ 4

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ СРЕДСТВАМ СЛУЖБЫ
ДОМЕННЫХ ИМЕН ПРОТОКОЛУ DNS

1. ОБЛАСТЬ ПРИМЕНЕНИЯ

Настоящее приложение описывает технические требования к ТС службы доменных имен по протоколу DNS в соответствии с RFC 1034 [12] и RFC 1035 [13]. В приложении приведены процедуры обращения клиента к распределенной базе данных доменных имен с целью получения информации, связанной с указанным доменным именем, а также описывает функционирование распределенной базы данных доменных имен.

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

2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К СЕРВЕРУ DNS

2.1. Соединения

2.1.1. Протокол нижнего уровня

Сообщения DNS должны передаваться в датаграммах UDP или с использованием виртуального соединения TCP.

Контрольные файлы DNS должны передаваться с использованием протоколов надежной передачи файлов по сети передачи данных.

2.1.2. Требования к использованию протокола UDP

При использовании протокола UDP на сервере должен использоваться порт с десятичным номером 53.

При использовании UDP максимальный размер сообщения DNS должен составлять 512 байт. Более длинные сообщения должны усекаться с установкой бита ТС заголовка сообщения (см. п. 4.1.2.). Протокол UDP не должен использоваться для пересылки зоны.

2.1.3. Требования к использованию протокола TCP

При использовании протокола TCP на сервере должен использоваться порт с десятичным номером 53.

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

При использовании TCP каждый семибитный символ, передаваемый по соединению TCP, должен передаваться в отдельном октете. При этом символ должен быть выровнен вправо, а старший бит октета установлен в 0.

2.1.4. Установление соединения и закрытие соединения

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

3. ПЕРЕЧЕНЬ И СТРУКТУРА ДАННЫХ, ПЕРЕДАВАЕМЫХ ПО ПРОТОКОЛУ DNS

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

3.1. Формат сообщений DNS

3.1.1. Формат сообщений DNS должен соответствовать п. 5.4.1.

3.1.2. Заголовок сообщения DNS должен состоять из полей: ID, QR, OPCODE, AA, ТС, RD, RA, Z, RCODE, QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT.

3.1.3. Формат записей ресурсов в сообщениях DNS должен соответствовать п. 5.3.2.

3.1.4. Должны поддерживаться следующие виды сообщений DNS:

запрос;

ответ.

3.1.5. Должен поддерживаться стандартный тип запроса. Порядок обработки запроса должен соответствовать п. 5.4.2.1.

3.1.6. Если поддерживается инверсный тип запроса, порядок его обработки должен соответствовать п. 5.4.2.2.

3.1.7. Должны поддерживаться следующие коды ответа:

0 - нет ошибки;

1 - ошибка формата запроса;

2 - внутренняя ошибка сервера;

3 - ошибка имени;

4 - данный вид запроса не реализован;

5 - отказ выполнения операции.

3.1.8. Если поддерживаются рекурсивные запросы, порядок согласования выполнения рекурсивного запроса должен соответствовать п. 5.5.5, а алгоритм обработки рекурсивного запроса должен соответствовать п. 5.5.2.

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

3.1.10. При выдаче ответа авторитетным сервером в поле АА заголовка ответа должна быть установлена 1.

3.1.11. При усечении сообщения в поле ТС заголовка сообщения должна устанавливаться 1.

3.1.12. Если в сервере реализована обработка инверсных запросов, формат запроса и ответа должен соответствовать п. 5.4.2.2.

3.2. Кодирование данных в сообщениях DNS

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

3.3. Сжатие сообщений

Если сервер DNS поддерживает сжатие сообщений, механизм сжатия должен соответствовать п. 5.4.3.

3.4. Контрольные файлы

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

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

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

4. ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ СЕРВЕРА DNS

4.1. Общие требования к реализации сервера DNS

4.1.1. УТС DNS должен обеспечивать функции сервера DNS и функции клиента DNS

4.1.2. При реализации кэширования отрицательных ответов к дополнительной секции авторитетного ответа должна добавляться запись RR типа SOA. Описание типа SOA дано в п. 5.3.2.1.6.

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

4.1.4. Должны поддерживаться записи RR с шаблонными именами владельца согласно п. 5.3.4.

4.1.5. Должен поддерживаться субдомен IN-ADDR.ARPA. согласно п. 5.2.4.

4.2. Требования к размеру элементов протокола

Максимальный размер элементов протокола должен соответствовать табл. 1

Таблица 1

Максимальный размер элементов протокола

4.3. Реализация вторичного сервера зоны

4.3.1. Если сервер поддерживает функции вторичного сервера зоны DNS, временные параметры REFRESH, RETRY, EXPIRE процедуры отслеживания изменений зоны на первичном сервере должны соответствовать значениям, установленным в записи RR SOA для данной зоны.

4.3.2. Получение измененной зоны должно выполняться при помощи запроса AXFR. Команда AXFR должна выдаваться первичному серверу при обнаружении увеличения параметра SERIAL записи RR SOA для данной зоны на первичном сервере.

4.4. Реализация первичного сервера зоны

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

5. ОПИСАНИЕ СИСТЕМЫ ДОМЕННЫХ ИМЕН

5.1. Структура системы доменных имен

5.1.1. Основные компоненты системы доменных имен.

В DNS входят три основные компоненты:

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

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

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

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

5.1.2. Основные конфигурации взаимодействия сервера, клиента и разрешающей системы в системе DNS.

Клиентом называется процесс, использующий функции системы доменных имен. Сервером имен называется процесс, выполняющий совместно с процессом клиента функции доступа к системе доменных имен. Внешний сервер имен - сервер имен, который взаимодействует с клиентом через разрешающую систему другого сервера.

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

Рисунок 1. Доступ клиента к пространству доменных имен через рекурсивный сервер имен

Рисунок 2. Доступ клиента к пространству доменных имен через нерекурсивный сервер имен

5.2. Структура пространства доменных имен

Пространство доменных имен является древовидной структурой. Каждый узел и лист дерева соответствует определенному набору данных о ресурсах. Этот набор данных может быть пустым. Доменная система одинаково использует внутренние узлы и листья дерева, поэтому далее листья называются тоже узлами дерева. Каждому узлу дерева присвоена метка длиной от 0 до 63 символов. Длина метки корневого узла должна быть равна 0.

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

Домен А называют субдоменом другого домена В, если А содержится в домене В. Кроме разделения на субдомены рассматривают разделение доменов на классы и зоны. Разделение домена на классы осуществляется в соответствии со значением поля CLASS записей RR, в которых хранится информация о домене. Разделение на зоны рассматривается в п. 6.2.3.

Замечание: Необходимо различать понятия «узел доменного дерева» и «узел сети передачи данных». Узел сети передачи данных может иметь несколько сетевых адресов, которым будут соответствовать несколько узлов доменного дерева. Узел сети передачи данных может вообще не иметь доменного имени и соответствующего узла доменного дерева.

5.2.1. Доменные имена

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

5.2.1.1. Внутренняя форма представления доменного имени

Каждая метка хранится в виде одного октета длины, за которым следует некоторое количество октетов, содержащих символы метки. Так как каждое доменное имя заканчивается нулевой меткой, обозначающей корень, представление каждого доменного имени заканчивается октетом длины, содержащим 0. Октет длины содержит два старших бита, установленных в 0. Оставшиеся 6 битов содержат значение длины поля символов метки от 0 до 63. Общая длина доменного имени (сумма всех октетов символов и октетов длин) не должна превышать 255 октетов.

Внутренняя форма представления доменного имени должна соответствовать следующему определению:

Все символы должны быть закодированы в ASCII

5.2.1.2. Печатная форма представления доменного имени

В печатной форме доменные имена представляются как список меток, разделенных одной точкой.

Все символы должны кодироваться в ASCII.

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

5.2.2. Псевдонимы и канонические имена

Узлы и другие ресурсы часто имеют несколько имен. Как правило одно из набора эквивалентных имен называют каноническим или первичным, а остальные - псевдонимами. Псевдоним присваивается узлу с помощью соответствующей записи RR типа CNAME. Запись RR типа CNAME содержит в разделе «владелец» псевдоним владельца, а в разделе RDATA - соответствующее каноническое имя. Если в узле присутствует RR типа CNAME, то не должно быть никаких других данных для этого узла.

Когда сервер имен не может найти желаемый RR в наборе, связанном с доменным именем, сервер проверяет, нет ли в наборе RR записей типа CNAME соответствующего класса. Если есть, сервер имен включает запись RR CNAME в ответ и возобновляет запрос к доменному имени, указанному в поле RDATA записи CNAME. Запросы, соответствующие типу CNAME, не возобновляются.

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

5.2.3. Зоны домена

5.2.3.1. Разбиение домена на зоны

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

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

Данные, описывающие зону, могут быть разделены на четыре части:

- Авторитетные данные для всех узлов данной зоны

- Данные, определяющие верхний узел зоны

- Данные, описывающие делегированные подзоны

- Данные, позволяющие получить доступ к доменным именам подзон (так называемые «клеевые» записи).

Все эти данные представлены в виде записей RR. Таким образом зона может быть полностью описана набором RR. Зона может быть перенесена с одного сервера имен на другой путем передачи записей RR либо путем передачи целого контрольного файла.

Записи RR, описывающие верхний узел зоны, разделяются на: записи NR RR, представляющие список всех серверов имен данной зоны, и одну запись SOA RR, описывающую параметры управления зоной.

Записи RR, описывающие «разрезы» на «дне» зоны (определяющие подзоны), обозначаются NS RR и указывают на сервер имен подзоны.

Данные NS RR не являются частью авторитетных данных зоны, так как определяют «разрезы» между узлами, а не узлы (так как не содержат адресной информации). Каждая запись NS RR должна быть идентична верхней записи RR соответствующей подзоны. В отдельной зоне записи NS RR должны располагаться рядом с верхним узлом зоны (они входят в число авторитетных) или на «разрезах» вокруг «дна» зоны (они не входят в число авторитетных), но никогда не должны располагаться посредине зоны.

Так как записи NS RR содержат только имена серверов подзон, но не содержат адресов серверов подзон, зона содержит «клеевые» записи RR (не являющиеся авторитетными), которые являются адресными RR для данных серверов. «Клеевые» RR используются в ссылочном ответе.

5.2.3.2. Распространение изменений зоны

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

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

Для проверки наличия изменений вторичные серверы проверяют поле SERIAL записи SOA данной зоны. Если в зоне производятся какие-либо изменения, значение поля SERIAL всегда увеличивается. Механизм изменения может быть либо простым увеличением значения, либо может использовать текущую дату.

Параметры периодической переклички вторичных серверов устанавливаются в SOA RR данной зоны. Этими параметрами являются: REFRESH, RETRY и EXPIRE. Когда вторичный сервер загружает новую зону, он ждет REFRESH секунд перед новой проверкой поля SERIAL. Если не обнаружено изменений (значение поля SERIAL - прежнее), вторичный сервер опять ждет REFRESH секунд. В случае, если проверка не может быть произведена, сервер ждет RETRY секунд до повторной проверки. Если вторичному серверу не удалось провести проверку в течение EXPIRE секунд, он должен считать копию зоны устаревшей и уничтожить ее.

Это значит, что в случаях ошибки чтения зоны или в случае просрочки обновления зоны, сервер имен должен выдавать ответы на запросы таким образом, как если бы он вообще не владел этой зоной. Во время пересылки новых данных о зоне сервер имен должен выдавать старые данные, пока пересылка не будет полностью закончена. Если вторичный сервер обнаружил, что на первичном сервере зона изменена, сервер должен запросить командой AXFR передачу зоны. Первое и последнее сообщения, передаваемые в ответ на команду, должны содержать данные для верхнего авторитетного узла в зоне. Промежуточные сообщения должны содержать остальные RR зоны, как авторитетные, так и неавторитетные. Команда AXFR должна использовать протокол TCP. Данный механизм копирования зон может применяться вторичными серверами не только к первичным серверам, но и к другим вторичным серверам.

5.2.4. Домен IN-ADDR.ARPA

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

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

Субдомен начинается с метки IN-ADDR.ARPA и имеет подструктуру, соответствующую структуре адресации Internet. Доменные имена могут иметь до 4-х меток в дополнение к IN-ADDR.ARPA. Каждая метка представляет собой один октет адреса IP в формате десятичного целого от 0 до 255 (с опущенными лидирующими нулями). Адрес узла соответствует имени, в котором присутствуют все 4 метки. Например, узел с адресом 10.2.0.52 будет иметь имя 52.0.2.10.IN-ADDR.ARPA.

Имена с количеством меток менее 4-х соответствуют зоне, выделенной для отдельной сети.

Сетевые номера соответствуют некоторым неконечным узлам, располагающимся на различной глубине домена IN-ADDR.ARPA. Сетевые узлы используются для хранения указателей на первичные узловые имена шлюзов, присоединенных к данной сети. Так как шлюз находится более чем в одной сети, имеются два или более сетевых узлов, указывающих на него. Шлюзы также имеют указатели уровня узла на их полные адреса. Шлюзовые указатели на сетевые узлы и обычные узловые указатели на полные сетевые адреса используют PTR RR для обратной ссылки на первичные доменные имена соответствующих узлов.

Пример:

Домен IN-ADDR.ARPA содержит информацию:

о шлюзе MILNET-GW.ISI.EDU между сетями 10 и 26 с адресами 10.2.0.22 и 26.0.0.103

о шлюзе GW.LCS.MIT.EDU между сетями 10 и 18 с адресами 10.0.0.77 и 18.10.0.4

об узле A.ISI.EDU

об узле MULTICS.MIT.EDU

Программа, желающая найти шлюз в сеть 10, выдаст запрос со значениями: QTYPE = PTR, QCLASS = IN, QNAME = 10.IN-ADDR.ARPA. и получит ответ с записями RR:

Разрешающая система, желающая найти имя узла с адресом 10.0.0.6, выдаст запрос со значениями: QTYPE = PTR, QCLASS = IN, QNAME = 6.0.0.10.IN-ADDR.ARPA и получит в ответ:

6.0.0.10.IN-ADDR.ARPA.

PTR

MULTICS.MIT.EDU.

Замечание: если узел имеет два имени в различных доменах, только одно из этих имен может быть каноническим.

5.3. Записи ресурсов

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

5.3.1. Общая структура записи ресурса RR

В отдельную запись ресурса RR входят разделы, приведенные в табл. 2.

Таблица 2

Разделы отдельной записи ресурса RR

Поле TTL интерпретируется как предел времени хранения RR в кэше. TTL не применяется для авторитетных данных внутри зоны. Для авторитетных данных внутри зоны применяется специальная временная организация. TTL назначается администратором для зоны, из которой поступают данные. TTL = 0 запрещает кэширование данных. Так, записи SOA всегда имеют TTL = 0. Если ожидается изменение RR, перед проведением изменения ее TTL может быть уменьшено для сокращения периода несоответствия во время замены. После проведения замены TTL увеличивается обратно до прежнего значения.

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

5.3.2. Формат представления RR в сообщении DNS

5.3.2.1. Формат RR приведен на рис. 3.

Рисунок 3. Формат представления RR

Описание значений полей формата RR приведено в табл. 3.

Таблица 3

Описание значений полей формата RR

5.3.2.2. Значения поля TYPE должны соответствовать табл. 4.

Таблица 4

Значения поля TYPE

5.3.2.3. Значения поля CLASS

Значения поля CLASS приведены в табл. 5.

Таблица 5

Значение поля CLASS

5.3.2.4. Формат и значения поля RDATA

Все символы должны быть закодированы в ASCII

Поле RDATA может иметь следующие типы форматов: CNAME-RDATA, HINFO-RDATA, MX-RDATA, NS-RDATA, PTR-RDATA, SOA-RDATA, TXT-RDATA, A-RDATA, WKS-RDATA.

5.3.2.4.1. CNAME-RDATA:: = domain-name

5.3.2.4.2. HINFO-RDATA:: = CPU OS

5.3.2.1.3. MX-RDATA:: = preference exchange

5.3.2.1.4. NS-RDATA:: = NSDNAME

5.3.2.1.5. PTR-RDATA:: = PTRDNAME

5.3.2.1.6. SOA-RDATA:: = MNAME RNAME SERIAL REFRESH RETRY EXPIRE MINIMUM

5.3.2.1.7. TXT-RDATA:: = 1*(character-string)

5.3.2.1.8. A-RDATA:: = ADDRESS

5.3.2.1.9. WKS-RDATA:: = ADDRESS PROTOCOL BIT-MAP

5.3.3. Формат RR в контрольных файлах

Большинство RR занимают единственную строку, хотя возможны строки продолжения с использованием скобок.

Для улучшения читаемости могут быть включены пустые строки.

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

Более подробно формат RR в контрольном файле описан в п. 6.4.4.

5.3.4. Шаблоны

Имя владельца в записи RR может начинаться с символа «*». Такие RR называются шаблонами. Наиболее часто шаблоны используются для создания зон, которые в свою очередь, используются для перенаправления почты из Internet в некоторую другую почтовую систему. Любое имя, соответствующее шаблону, будет принадлежать такой зоне и обладать определенными свойствами согласно данным, указанным в RR с шаблоном, если только не существует RR, точно соответствующий имени.

Шаблоны не применяются, когда:

- запрос принадлежит другой зоне,

- известно, что существует запрашиваемое имя либо имя между запрашиваемым именем и шаблоном.

Например, если есть RR-шаблон с именем владельца «*.Х» и в данной зоне также содержатся RR, прикрепленные к В.Х, шаблоны будут применяться к запрашиваемому имени Z.X, но не к запрашиваемому имени В.Х, А.В.Х или X.

Символ «*» в запрашиваемом имени не имеет специального значения, но может использоваться для тестирования шаблонов в авторитетной зоне. Запрос с «*» является единственным способом получить ответ, содержащий RR-шаблоны. Результат такого запроса не должен кэшироваться.

Пример использования шаблонов:

Пусть существует большая компания с большой сетью не-ТСР/IP. Эта компания хочет создать почтовый шлюз. Если компания названа Х.СОМ, и шлюз ТСР/IР назван А.Х.СОМ, то в зону СОМ могут быть введены следующие записи RR.

Данные записи будут заставлять сервер на любой запрос MX для любого доменного имени, заканчивающегося Х.СОМ возвращать запись MX RR, указывающую на А.Х.СОМ. Последний шаблон необходим, так как действие первого шаблона перекрывается 4-й строкой.

5.4. Взаимодействие по протоколу DNS

Взаимодействие по протоколу DNS осуществляется путем обмена сообщениями DNS и контрольными файлами DNS.

5.4.1. Формат сообщений DNS

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

Рисунок 4. Формат сообщения DNS

Секция заголовка является обязательной.

Формат заголовка показан на рис. 5.

Рисунок 5. Формат заголовка DNS

Описание полей заголовка DNS приведено в табл. 6.

Таблица 6

Описание полей заголовка DNS

Формат секции запроса показан на рис. 6.

Рисунок 6. Формат секции запроса

Описание формата секции запроса приведено в табл. 7.

Таблица 7

Формат секции запроса

5.4.2. Типы запросов и соответствующие им ответы

Ответ сервера имен либо отвечает на запрос, либо ссылается на другое множество серверов имен, либо сигнализирует состояние ошибки.

Как правило, клиенты не генерируют запросы к серверу имен непосредственно, а используют разрешающую систему, которая в свою очередь, посылает один или несколько запросов серверу имен, а затем обрабатывает ошибки и результаты запросов. Тип запроса определяется значением 4-битного поля заголовка opcode. Opcode может иметь значения, трактуемые как стандартный запрос, инверсный запрос или запрос статуса. Четыре секции запроса, следующие за заголовком, описаны в табл. 8.

Таблица 8

Секции запроса, следующие за заголовком

Содержание секций зависит от кода поля opcode.

5.4.2.1. Стандартные запросы

Стандартный запрос представляет собой целевое доменное имя QNAME, тип запроса (QTYPE) и класс запроса (QCLASS). Выполнение его предполагает возвращение соответствующих записей RR. Длина полей QTYPE и QCLASS составляет 16 бит. Поле QTYPE может содержать значения, приведенные на рис. 7.

Рисунок 7. Значения поля QTYPE

Поле QCLASS может содержать значения, приведенные на рис. 8.

Рисунок 8. Значения поля QTYPE

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

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

5.4.2.2. Инверсные запросы

Сервер имен может поддерживать инверсные запросы. Если сервер имен не поддерживает инверсный запрос, на подобный запрос он должен выдать ответ «Не реализовано» (Not-implemented).

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

В ответ на инверсный запрос сервер имен должен выдать:

- 0, одно или несколько доменных имен в секции QNAMES для указанного ресурса;

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

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

В ответе на инверсный запрос может не содержаться истинный TTL, и могут не указываться случаи, когда идентифицированная RR является одной из множества. Поэтому записи RR, получаемые из ответов на инверсные запросы, не должны кэшироваться.

5.4.3.1 Сжатие сообщений

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

Формат указателя должен соответствовать рис. 9.

Рисунок 9. Формат указателя

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

Метод сжатия позволяет доменному имени в сообщении быть представленным в одной из трех форм:

- доменное имя во внутреннем формате - последовательность меток с нулевым октетом в конце

- указатель

- последовательность меток с указателем в конце.

Реализация метода сжатия сообщений является не обязательной.

5.4.4. Контрольные файлы

Контрольные файлы - это текстовые файлы, содержащие записи RR в текстовой форме.

5.4.4.1. Формат контрольного файла

Контрольный файл состоит из набора записей. Возможен перенос записи на следующую строку с использованием скобок. Комментарии начинаются с символа «;» (точка с запятой). Символы пробелов и табуляции выполняют функции разделителей между элементами позиции.

В контрольном файле могут быть записи следующего формата:

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

domain-name - имя домена в символьной форме.

Имена доменов, заканчивающиеся символом «.» (точка), называются абсолютными и считаются полными именами.

Доменные имена, не заканчивающиеся символом «.» (точка), называются относительными.

Полное доменное имя получается соединением относительного имени и текущего основания относительного имени. Употребление относительного имени в случае неустановленного основания является ошибкой.

Позиция $ORIGIN переустанавливает текущее основание относительного доменного имени.

Позиция $INCLUDE вставляет указанный файл в текущий контрольный файл. Позиции $ORIGIN вставляемого файла не оказывают влияния на текущее основание относительного имени в родительском контрольном файле.

Элемент rr обозначает представление записи RR.

Если поля TTL или class пропущены, то берутся предыдущие точно объявленные значения.

5.4.4.2. Использование специальных символов в контрольном файле

Строка символов (character-string) может быть представлена непрерывным набором символов без пробелов внутри или произвольным набором символов с пробелами, заключенным в двойные кавычки. Во втором случае, если в исходной строке встречается символ кавычки, перед ним должен быть вставлен символ \.

Возможны следующие специальные символы:

5.4.4.3. Использование контрольного файла для определения зон

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

- Все RR файла должны иметь один и тот же класс

- Должна присутствовать только одна запись SOA RR

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

Пример контрольного файла, содержащего одну зону:

5.5. Разрешающая система

5.5.1. Функции разрешающей системы

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

Клиентский интерфейс разрешающей системы выполняет три основные функции:

- трансляция имени в адрес узла

- трансляция адреса в имя узла

- функция общего поиска

В качестве ответа клиенту разрешающая система может выдать:

- одну или несколько RR

- ошибку имени NE

- ошибку «данные не найдены»

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

5.5.2. Алгоритм работы разрешающей системы.

5.5.2.1. Шаг 1. Проверить, есть ли ответ на запрос в локальной информации. Если есть, выдать ответ клиенту. Поиск происходит в кэшированных данных. Если данные найдены, они предполагаются подходящими для нормального использования. Разрешающие системы могут форсированное игнорирование кэшированных данных по запросу клиента.

5.5.2.2. Шаг 2. Найти наилучшие серверы для продолжения запроса. Поиск серверов имен и занесение их в SLIST. Сначала в локально доступных NS RR серверов имен, ищется SNAME, затем имя родительского домена SNAME, затем прародительского и т.д. до корня. Если поиск заканчивается неудачей, разрешающая система инициализирует SLIST из SBELT.

5.5.2.3. Шаг 3. Отправить запросы и ждать, пока не придет ответ хотя бы на один из них.

5.5.2.4. Шаг 4. Анализировать ответ:

если ответ удовлетворяет запросу или содержит ошибку имени, данные кэшируются и возвращаются клиенту

если ответ содержит лучшую ссылку на другие серверы, кэшировать ссылочную информацию и перейти к шагу 2

если ответ показывает CNAME и не удовлетворяет запросу, кэшировать CNAME, заменить SNAME на каноническое имя из CNAME RR и перейти к шагу 1

если ответ показывает ошибку сервера или другую ненормальную информацию, удалить имя сервера из SLIST и вернуться к шагу 3.

5.5.3. Кэширование отрицательных ответов.

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

5.5.4. Работа разрешающей системы с псевдонимами

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

5.5.5. Рекурсивный режим работы сервера

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

- во всех ответах сервера устанавливается в «1» бит RA - рекурсия доступна.

- запрос клиента содержит бит RD - рекурсия желательна.

Если установлены оба бита RA и RD, то при необходимости используется режим рекурсии.

Возможны следующие варианты ответов:

1. Рекурсия разрешена

- ответ на запрос, возможно предшествуемый одной или двумя CNAME RR

- ошибка имени, указывающая, что имя не существует. Может включать CNAME RR, указывающую, что запрос содержал псевдоним, для которого не существует канонического имени.

- индикация временной ошибки

2. Рекурсия запрещена

- ошибка имени, указывающая, что имя не существует

- индикация временной ошибки

- некоторая комбинация:

RR, отвечающих на запрос вместе с информацией, являются ли эти RR кэшированными

Ссылка на сервер имен

- дополнительные RR, являющиеся по мнению сервера полезными запросчику.

ПРИЛОЖЕНИЕ 5

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ СРЕДСТВАМ СЛУЖБЫ
ДОСТУПА К ИНФОРМАЦИОННЫМ РЕСУРСАМ ПО ПРОТОКОЛУ HTTP

1. ОБЛАСТЬ ПРИМЕНЕНИЯ

Настоящее приложение описывает технические требования к ТС службы доступа к информационным ресурсам а по протоколу HTTP в соответствии с RFC 2068 [14]. В приложении приведены операции взаимодействия клиента с различными типами ресурсов сети передачи данных, доступ к которым осуществляется посредством сервера HTTP. Определяются операции получения клиентом содержимого ресурса, согласования представления ресурса, передачи информации клиента на адрес ресурса, идентификации клиента.

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

2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К СЕРВЕРУ HTTP

2.1. Соединения

2.1.1. Протокол нижнего уровня

Сообщения HTTP должны передаваться с использованием виртуального соединения TCP.

2.1.2. Установление соединения и закрытие соединения

При обмене сообщениями HTTP соединение должно инициироваться стороной клиента. Если сервер поддерживает стойкие соединения (см. п. 5.7.), то перед закрытием соединения он должен в сообщение ответа включить поле Connection с меткой close. Если сервер поддерживает стойкие соединения, то при получении запроса с полем Connection со значением close, он должен ответить на данный запрос и закрыть соединение.

2.1.3. Если сервер поддерживает стойкие соединения, он должен обеспечивать функцию перекачки сообщений клиента в соответствии с п. 5.7.1.1.2.

3. ПЕРЕЧЕНЬ И СТРУКТУРА СООБЩЕНИЙ ПРОТОКОЛА HTTP

3.1. Требования к элементам сообщений

3.1.1. В сообщении HTTP должен использоваться формат адреса URI в соответствии с п. 5.2.2.

3.1.2. В сообщении HTTP должен использоваться один из форматов представления даты, приведенных в п. 5.2.3.1.

3.1.3. Промежутки времени в полях сообщения HTTP должны указываться в секундах в виде десятичного числа.

3.2. Типы информации

3.2.1. Процедура согласования содержимого

3.2.1.1. Если сервер поддерживает управляемую сервером процедуру согласования содержимого, он должен использовать поле Vary для указания пределов варьирования представления ресурса. При осуществлении выбора представления сервер должен использовать информацию из полей Accept, Accept-Charset, Accept-Encoding, Accept-Language, Accept-Ranges в соответствии с п. 5.12.1., 5.12.2., 5.12.3., 5.12.4., 5.12.5.

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

3.2.2. Если сервер отправляет ответ с типом информации, отличным от application/octet-stream, он должен указать данный тип в поле Content-Type. Обозначение типа должно соответствовать RFC 2048 [15].

3.2.3. Если к телу сообщения применяется преобразование, тип преобразования должен быть указан в поле Transfer-Encoding в соответствии с п. 5.12.40.

3.3. Запросы

3.3.1. Структура запросов протокола HTTP должна соответствовать п. 5.3.

3.3.2. В сервере должна быть реализована обработка запросов методами GET, HEAD.

3.3.2.1. Если в сервере реализована обработка условных запросов методами GET, HEAD, то для задания условия должны использоваться поля заголовка запроса:

If-Modified-Since;

If-Match;

If-None-Match;

If-Range;

If-Unmodified-Since.

При этом содержание полей должно обрабатываться согласно п. 5.12.24, 5.12.25, 5.12.26, 5.12.27, 5.12.28.

3.3.2.2. Если в сервере реализована обработка запросов диапазонов методом GET, то для задания диапазона должно использоваться поле Range. Содержимое поля Range должно интерпретироваться в соответствии с п. 5.12.36.

3.3.3. Для предоставления клиенту возможности запрашивать информацию о параметрах соединения с запрашиваемым URI должен использоваться метод OPTIONS (раздел 5.8.2).

3.3.4. Для предоставления клиенту возможности передачи на ресурс с указанным URI дополнительной информации в виде сущности должен использоваться метод POST (п. 5.8.5).

3.3.5. Для предоставления клиенту возможности сохранения на сервере сущности под указанным URI должен использоваться метод PUT (п. 5.8.6). Если в результате запроса клиента сервер создал новый ресурс, он должен выдать ответ 201. В случае невозможности сохранить сущность под указанным URI сервер должен выдать ответ 301.

3.3.6. Для предоставления клиенту возможности удаления ресурса с указанным URI должен использоваться метод DELETE (п. 5.8.7).

3.3.7. Метод TRACE используется для организации удаленного шлейфа (п. 5.8.8). Конечному получателю запроса следует направить полученное сообщение обратно клиенту в качестве тела сущности. При этом клиент должен выдать сообщение 200. Конечный получатель - это либо первоначальный сервер, либо первый прокси или шлюз для получения значения 0 в ответ. Запрос TRACE не должен включать сущность.

3.4. Ответы

3.4.1. Структура ответов сервера должна соответствовать п. 5.5.

3.4.2. Сервер должен поддерживать ответы с кодами статуса, приведенные в табл. 1.

Таблица 1

Ответы с кодами статуса

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

3.4.4. В ответе сервера обязательно должно присутствовать поле Age, значение которого должно вычисляться согласно п. 5.12.6.

3.4.5. В ответе сервера обязательно должно присутствовать поле Date, содержащее дату и время генерации сообщения сервером.

3.5. Взаимодействие клиента и сервера

3.5.1. Сервер не должен выдавать ответ 100 клиенту с версией HTTP ниже 1.1.

4. ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ СЕРВЕРА HTTP

4.1. Требования к функциям кэша

4.1.1. Если в сервере реализованы функции кэша, они должны соответствовать п. 5.11.

4.1.2. Ответы на запрос с методом OPTIONS не должны кэшироваться.

4.1.3. Если кэш выдает устаревший ответ, в него должно быть включено предупреждение 10 (см. п. 5.12.45, табл. 3).

4.1.4. Если кэш не может провести проверку актуальности ответа, в данный ответ должно быть включено предупреждение 11 (см. п. 5.12.45, табл. 3).

4.1.5. Если кэш применяет преобразование содержимого тела сообщения, изменяющее его кодировку или тип информации, он должен включить в сообщение предупреждение 14 (см. п. 5.12.45, табл. 3).

4.1.6. Кэш должен обрабатывать ответы как устаревшие, если они имеют значение поля Expires более позднее, чем текущая дата или, если формат поля Expires не соответствует формату даты по п. 3.1.2. настоящих Технических требований.

4.2. Требования к функциям сервера прокси

4.2.1. Если в сервере реализованы функции сервера прокси, они должны соответствовать п. 5.11.

4.2.2. Сервер прокси не должен устанавливать стойкие соединения с клиентами версии HTTP/1.0. и ниже.

4.2.3. Если через прокси проходит ответ на запрос с методом OPTIONS, прокси должен исправить содержимое полей ответа, а также добавить или удалить поля ответа в соответствии с поддерживаемыми им возможностями.

4.2.4. Если сервер прокси не выполняет функции межсетевого экрана, он должен добавлять в поле Via проходящих через него сообщений свой идентификатор в соответствии с п. 5.12.44. Если сервер прокси выполняет выполняет функции межсетевого экрана, то он должен иметь сертификат Гостехкомиссии России.

4.2.5. Если в прокси реализована процедура идентификации клиента, она должна выполняться с использованием полей заголовка Proxy-Authenticate и Proxy-Authorization в соответствии с п. 5.12.33. и 5.12.34.

4.2.6. Прокси должен добавлять в сообщение запроса поле Host, если данное поле отсутствует в сообщении.

4.2.7. Прокси, получивший сообщение с методом TRACE и полем Max-Forwards = 0, не должен направлять данное сообщение, а должен выдать ответ 200 с данным сообщением, включенным в сущность ответа.

4.3. Идентификация доступа

4.3.1. Для начала процедуры идентификации должен использоваться ответ 401 с полем WWW-Authenticate. В процедуре идентификации должно использоваться содержимое поля запроса Authorization. Если сервер не принимает сообщение клиента с полем Authorization, он снова должен выдать ответ 401.

4.3.2. Если сервер поддерживает первичную схему идентификации доступа, ее реализация должна соответствовать п. 5.9.1.

4.4. Согласование протокола

Если сервер поддерживает процедуру согласования протокола, данная процедура должна быть реализована в соответствии с п. 5.12.41.

5. ОПИСАНИЕ ПРОТОКОЛА HTTP

5.1. Базовые определения

Спецификация синтаксиса запросов и ответов HTTP приводится в расширенной форме Наура-Бекуса соответствующей RFC-822 [2].

Базовые определения:

Заголовок HTTP может быть разбит на несколько строк. 2-я и далее строка заголовка должны начинаться с пробела или табуляции.

LWS:: = [CRLF] 1*(SP HT)

Слова *ТЕХТ могут содержать символы набора, отличного от ISO 8859-1 [16] только в случае, если они закодированы в соответствии с RFC 2047 [17].

Если в значении поля заголовка содержатся специальные символы, эти специальные символы должны содержаться в строке в кавычках.

comment:: = «(« *(ctext comment) «)»

ctext:: = <любой TEXT кроме «(» и «)»>

Строка текста, заключенная в двойные кавычки («строка в кавычках»), обрабатывается как единое слово.

quoted-string:: = (<«> *(qdtext) <«>)

qdtext:: = <any TEXT except <«>>

Конструкция квотирования «\<символ>» может использоваться только внутри «строки в кавычках» и комментария.

quoted-pair:: = «\» CHAR

5.2. Элементы протокола

5.2.1. Версия HTTP

Версия содержится в поле HTTP-Version в первой строке сообщения.

HTTP-Version = «HTTP» «/» 1*DIGIT «.» 1*DIGIT

Номер DIGIT не должен начинаться с нулей.

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

5.2.2. Универсальный идентификатор ресурса (URI)

5.2.2.1. Синтаксис

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

Если длина URI превышает максимальную длину, обрабатываемую сервером, сервер должен выдать ответ статуса 414.

5.2.2.2. HTTP URL

URL - универсальный указатель расположения ресурса. URL - тип URI, со схемой http.

Если port не указан, предполагается порт по умолчанию 80. Если в запросе не указан abs_path, вместо него должен присутствовать «/».

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

- если порт не указан, он считается эквивалентным порту по умолчанию;

- при сравнении имен узлов регистр символов не должен учитываться;

- при сравнении схем регистр не должен учитываться;

- пустой абсолютный путь abs_path эквивалентен значению «/» abs_path.

Символы, не входящие в группы «reserved» и «unsafe» эквивалентны их коду, представленному как «« %» HEX HEX».

5.2.3. Формат даты и времени

5.2.3.1. Полная дата

Существует три допустимых формы представления даты/времени:

Время и дата, указанные в метках даты/времени, должны соответствовать Среднему Гринвичскому времени.

5.2.3.2. Период в секундах

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

delta-seconds:: = 1*DIGIT

5.2.4. Наборы символов

Термин «набор символов» в протоколе HTTP аналогичен такому же термину, определенному в протоколе MIME.

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

сharset:: = token

где значение token должно соответствовать RFC 1700 [9].

5.2.5. Кодирование содержимого

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

content-coding:: = token

Определены следующие значения token: gzip (GNU zip согласно RFC 1952 [21]) и compress.

5.2.6. Кодирование при передаче

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

transfer-coding:: = «chunked» transfer-extension

transfer-extension:: = token

Порционное кодирование (chunked encoding) изменяет тело сообщения таким образом, что оно передается как последовательность порций. Каждая порция имеет свой индикатор размера, за которым следует необязательный раздел, содержащий поля заголовка сущности. Таким образом кодирование при передаче позволяет передавать сообщения с динамически генерируемым содержимым.

5.2.7. Типы информации

Для обеспечения открытого определения и согласования типа информации используются поля заголовка Content-Type и Accept.

Между элементами type и subtype, а также между parameter и value не должны использоваться символы LWS в качестве разделителя. Значения media-type должны соответствовать RFC 2048 [15].

5.2.7.1. Канонические представления информации

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

5.2.7.1.1. Тип text.

В качестве разделителя линии в теле сообщения при типе media-type text могут использоваться отдельные символы CR, LF и пара символов CRLF. Если не указан набор символов, по умолчанию должен использоваться ISO-8859-1 [16].

5.2.7.2. Если сообщение содержит несколько тел с различными типами информации, все части сообщения должны иметь формат MIME. В отличие от MIME эпилог (epilogue) не должен передаваться.

5.2.8. Метки продуктов

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

Например:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Server: Apache/0.8.4

5.2.9. Параметр качества содержимого

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

5.2.10. Теги языка

Теги языка указывают на естественный язык, используемый для передачи информации между людьми. Синтаксис и допустимое содержание тега языка должны соответствовать RFC 1766 [22].

Первый двухсимвольный тег primary-tag - это аббревиатура языка в соответствии с ISO 639 [23], а первый двухбуквенный subtag - это код страны по ISO 3166 [24].

5.2.11. Теги сущности

Теги сущности используются для сравнения двух или более сущностей, поступивших от одного запрашиваемого ресурса.

Теги сущности должны быть уникальны для всех версий всех сущностей, относящихся к отдельному ресурсу.

5.2.12. Блоки диапазонов

HTTP 1.1 позволяет клиенту затребовать, чтобы только часть (диапазон) сущности ответа была включена в ответ. Сущность может быть разбита на поддиапазоны в соответствии с различными структурными блоками.

Единственным обязательным для реализации блоком является bytes-unit.

5.3. Сообщение HTTP

5.3.1. Типы сообщений

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

Запросы и ответы используют общий формат сообщений RFC 822 [2] для передачи сущностей (полезной нагрузки сообщения). Оба типа сообщения состоят из начальной строки, одной или более строк заголовка, пустой строки, указывающей на конец заголовка, и необязательного тела сообщения.

Сервер должен игнорировать пустые строки, поступающие перед Request-Line.

5.3.2. Заголовки сообщений

Поля заголовка HTTP, включая поля общего заголовка, заголовка запроса, заголовка ответа и заголовка сущности, должны соответствовать формату п. 3.1 RFC 822 [2]. Поля заголовка могут занимать несколько строк, но строки, следующие за первой, должны начинаться с 1 *(SP HT).

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

5.3.3. Тело сообщения

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

Ответы 1хх (информационные), 204 (нет содержимого) и 304 (не изменен) не должны содержать тело сообщения. Все остальные ответы должны содержать тело, хотя возможно и нулевой длины.

На наличие тела сообщения указывает присутствие полей Content-Length и Transfer-Encoding.

5.3.4. Длина сообщения

При включении тела сообщения в сообщение, длина (конец) этого тела сообщения определяется следующим образом:

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

2. Если присутствует поле заголовка Transfer-Encoding и указывает на применение порционного кодирования, то длина определяется порционным кодированием.

3. Если присутствует поле Content-Length, его значение определяет длину тела сообщения в байтах.

4. Если сообщение использует тип информации «multipart/byteranges», который является самоограничивающимся, то этот тип информации определяет длину тела сообщения. Этот тип информации должен использоваться сервером только тогда, когда в запросе присутствует заголовок Range с несколькими определителями byte-range, который показывает, что клиент может обработать ответ «multipart/byteranges».

5. Закрытием соединения (только для тела ответа).

Сообщения не должны содержать одновременно поле Content-Length и поля порционного кодирования. В случае получения подобного сообщения значение Content-Length должно игнорироваться.

5.3.5. Общие поля заголовка

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

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

5.4. Запрос

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

5.4.1. Request-Line (Строка запроса)

Request-Line начинается с метки метода, за которым следует Request-URI и версия протокола, заканчивающаяся CRLF. Элементы разделены символами SP. Появление символов CR или LF, кроме заключительной последовательности CRLF, запрещено.

5.4.1.1. Method (Метод)

Регистр символа слова, обозначающего метод, является существенным.

Поддержка методов GET и HEAD является обязательной для реализации сервера.

5.4.1.2. Request-URI (URI запроса)

Request-URI определяет ресурс, к которому применяется запрос. Символ «*» показывает, что запрос должен применяться не к отдельному ресурсу, а к серверу в целом.

5.4.2. Идентификация ресурса

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

5.4.2.1. Если Request-URI является absoluteURI, тогда имя узла является частью Request-URI, и поле Host должно игнорироваться.

5.4.2.2. Если Request-URI не является absoluteURI, и запрос включает поле заголовка Host, узел определяется значением Host.

5.4.2.3. Если узел, определенный с помощью правил 5.4.2.1 и 5.4.2.2., не является действительным узлом на сервере, сервер должен выдать ответ 400.

5.4.3. Поля заголовка запроса.

Поля заголовка запроса позволяют клиенту передать дополнительную информацию о запросе и о самом клиенте.

5.5. Ответ

После получения и обработки сообщения запроса сервер отвечает сообщением ответа:

5.5.1. Status-Line (Строка статуса)

Строка статуса содержит версию протокола и дополнительную текстовую фразу. Строка статуса не может разрываться символами CR или LF.

5.5.1.1. Status-Code (код статуса)

Первая цифра поля Status-Code определяет класс ответа. Возможные значения приведены в табл. 2.

Таблица 2

Первая цифра поля Status-Code.

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

5.5.2. Поля заголовка ответа

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

5.6. Сущность

Сущность состоит из полей заголовка сущности и необязательного тела сущности.

5.6.1. Поля заголовка сущности

5.6.2. Тело сущности

Формат и кодирование тела сущности определяется значением полей заголовка сущности.

5.6.2.1. Тип

Тип данных тела сущности определяется полями заголовка Content-Type и Content-Encoding.

Поле Content-Type определяет тип информации. Поле Content-Encoding должно присутствовать обязательно. Если поле Content-Type отсутствует, по умолчанию принимается тип информации «application/octet-stream».

5.6.2.2. Длина тела сущности - это длина тела сообщения после удаления транспортного кодирования.

5.7. Соединения

5.7.1. Стойкие соединения

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

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

5.7.1.1. Общее функционирование

В версии 1.1 протокола HTTP стойкие соединения используются по умолчанию. Стойкие соединения предоставляют механизм, по которому клиент и сервер могут выдавать сигнал о закрытии соединения TCP. Для этого используется поле заголовка Connection. После того, как было просигнализировано закрытие, клиент не должен передавать запросы по этому соединению.

5.7.1.1.1. Согласование

Если сервер хочет закрыть соединение, он должен сигнализировать об этом в поле Connection. Если клиент хочет закрыть соединение, он должен сигнализировать об этом в поле Connection.

5.7.1.1.2. Перекачка

Клиент, поддерживающий стойкие соединения, может «перекачивать» свои запросы, то есть высылать несколько запросов, не дожидаясь ответов на каждый запрос. Сервер должен высылать ответы в порядке получения запросов.

5.7.1.2. Прокси

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

5.7.1.3. Требования к реализации

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

Сервер HTTP версии 1.1 при обработке запроса клиента HTTP версии 1.0 (или более раннего) не должен передавать ответ 100. Он должен либо дождаться окончания обработки запроса, либо преждевременно закрыть соединение.

При получении метода в соответствии с разделом 6.8 от клиента HTTP версии 1.1 сервер HTTP версии 1.1 должен либо выдать ответ 100 и продолжить чтение входного потока, либо выдать сообщение об ошибке. При выдаче сообщения об ошибке сервер не должен выполнять запрошенный метод.

5.8. Определения методов

5.8.1. Безопасные и идемпотентные методы

5.8.1.1. Безопасные методы

Безопасными называют методы GET (п. 5.8.3) и HEAD (п. 5.8.4). Они всегда означают действия получения, в которых клиент не отвечает за непредвиденный побочный эффект от их выполнения, в отличие от методов POST (п. 5.8.5), PUT (п. 5.8.6) и DELETE (п. 5.8.7).

5.8.1.2. Идемпотентные методы

Идемпотентными называют методы GET (п. 5.8.3), HEAD (п. 5.8.4), PUT (п. 5.8.6) и DELETE (п. 5.8.7), для которых побочный эффект от выполнения нескольких идентичных запросов будет равен побочному эффекту от выполнения одного запроса.

5.8.2. Метод OPTIONS

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

Если в поле Request-URI установлен символ «*», запрос относится к серверу в целом.

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

На запрос с методом OPTIONS сервер должен выдать ответ 200.

5.8.3. Метод GET

Метод GET позволяет получить любую информацию (в форме сущности), указанную полем Request-URI.

Если сообщение запроса содержит поля заголовка If-Modified-Since, If-Match, If-None-Match или If-Range, метод GET называют условным («conditional GET»).

Если сообщение запроса содержит поле заголовка Range, метод GET называют частичным («partial GET»).

5.8.4. Метод HEAD

Метод HEAD идентичен методу GET за исключением того, что сервер не должен возвращать тело сообщения в ответе.

5.8.5. Метод POST

Метод POST используется для выполнения запроса, в результате которого сервер назначения принимает содержащуюся в запросе сущность, как новую придаточную часть ресурса, определяемого Request-URI в строке запроса Request-Line.

5.8.6. Метод PUT

Метод PUT используется для выполнения запроса, в результате которого сущность, содержащаяся в запросе, сохраняется под указанным Request-URL.

Если создан новый ресурс, сервер должен выдать ответ 201.

Получатель запроса не должен игнорировать поля заголовка Content-* (Например, Content-Range), которые он не понимает или не поддерживает, а должен выдать ответ 501. В случае невозможности сохранения сущности под указанным URI, сервер не должен сохранять сущность под другим URI, а должен выдать ответ 301.

5.8.7. Метод DELETE

Метод DELETE используется для выполнения запроса, в результате которого сервер удаляет ресурс, идентифицируемый Request-URI.

Сервер может не поддерживать данный метод вообще, либо не поддерживать его для отдельных ресурсов и типов ресурсов.

5.8.8. Метод TRACE

Метод TRACE используется для организации удаленного шлейфа для сообщения запроса. Окончательный получатель запроса должен вернуть данный запрос в теле сущности ответа 200.

Запрос TRACE не должен включать сущность.

Ответы на данный запрос не должны кэшироваться.

5.9. Идентификация доступа

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

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

auth-scheme:: = token

auth-param:: = token « = « quoted-string

Challenge:: = auth-scheme 1*SP realm *(«,» auth-param)

realm:: = «realm» « = « realm-value

realm-value:: = quoted-string

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

Клиент, желающий выполнить процедуру идентификации, должен после получения ответа 401 или 411 (п. 3.4.2, табл. 1) выдать запрос с полем заголовка Authorization. Значение поля Authorization должно состоять из мандатов (credentials), содержащих идентифицирующую информацию о клиенте для указанной в идентификационном вызове защищаемой области.

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

Если сервер не принимает запрос с мандатами, он может выдать ответ 401 (п. 3.4.2, табл. 1). При этом ответ 401 должен содержать поле заголовка WWW-Authenticate.

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

Прокси должен быть абсолютно прозрачен для процедуры идентификации клиента.

5.9.1. Первичная схема идентификации

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

WWW-Authenticate: Basic realm = «WallyWorld»

Ответный запрос клиента содержит мандат, состоящий из идентификатора и пароля пользователя, разделенных двоеточием и закодированным в кодировке base64.

Пример ответного запроса клиента:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ = =

5.10. Согласование содержимого

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

5.10.1. Управляемое сервером согласование содержимого

В случае управляемого сервером согласования данных сервер на основе данных запроса делает предположение о наилучшем для клиента типе информации для данного ресурса. Для согласования содержимого сервером используются следующие поля заголовка запроса пользователя:

Accept, Accept-Charset, Accept-Encoding, Accept-Language, User-Agent.

В случае управляемого сервером согласования данных сервер-источник должен включать в каждый кэшируемый ответ поле Vary.

5.10.2. Управляемое клиентом согласование содержимого

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

5.10.3. Прозрачное согласование

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

5.11. Функционирование кэша и прокси

5.11.1. Ответы с кодом статуса 206 не должны кэшироваться.

5.11.2. Кэш и прокси не должны изменять или добавлять ни в запросе ни в ответе поля Content-Location, ETag, Expires, Last-Modified.

5.11.3. В ответе, содержащем директиву Cache-Control со значением no-transform, и в любом запросе кэш и прокси не должны изменять или добавлять следующие поля: Content-Encoding, Content-Length, Content-Range, Content-Type. Если кэш или прокси изменяют или добавляют эти поля, они должны при этом добавить предупреждение 14 (см. п. 5.12.45, табл. 3), если только в данном сообщении уже нет предупреждения 14.

5.11.4. Выполнение проверки актуальности

Если кэш выполняет запрос проверки актуальности к серверу, и сервер выдает ответ 304, кэш должен составить и отправить ответ клиенту, а также заменить поля заголовков хранящихся в кэше позиций (включая поля, указанные в п. 5.11.2. и 5.11.3.) на значения, полученные в ответе 304.

5.11.5. Кэш, который получает неполный ответ (например, с меньшим количеством байт данных, чем указано в поле Content-Length заголовка), в случае, если он сохраняет данный ответ, должен его обрабатывать как частичный. Частичные ответы могут комбинироваться в кэше. Кэш должен выдавать частичный ответ только используя код статуса 206.

5.11.6. Кэш не должен обрабатывать ответы, в которых в части rel_path URL содержатся символы «?», если только в них не указано точное время истечения.

5.12. Определения полей заголовка

5.12.1. Accept

Поле заголовка запроса Accept определяет типы информации, которые являются приемлемыми для ответа.

Символ «*» используется для группирования типов информации в диапазоны. При этом «*/*» означает все типы данных, а «тип/*» - все подтипы данного типа.

Пример:

Будет означать: предпочтительными типами информации являются text/html и text/x-с, но если таких нет, тогда нужно выслать сущность с типом text/x-dvi. А если и такого нет, тогда выслать text/plain.

5.12.2. Accept-Charset

Поле заголовка запроса Accept-Charset используется для указания наборов символов, приемлемых в ответе:

Например:

Если данное поле отсутствует, считается, что для клиента приемлем любой набор символов.

5.12.3. Accept-Encoding

Поле заголовка запроса аналогично полю Accept, но определяет приемлемые методы кодирования содержимого.

Например:

5.12.4. Accept-Language

Поле заголовка запроса аналогично полю Accept, но определяет приемлемые естественные языки, используемые в ответе:

По умолчанию определитель качества q = 1.

Пример:

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

5.12.5. Accept-Ranges

Поле ответа Accept-Ranges позволяет серверу указать приемлемые диапазоны в запросах к ресурсу.

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

5.12.6. Age

Поле ответа Age содержит приблизительный период времени, прошедший с момента отправки ответа сервером-источником.

Age:: = «Age» «:» age-value

age-value:: = delta-seconds

Значения Age должны рассчитываться кэшем следующим образом:

apparent_age = max(0, response_time - date_value);

corrected_received_age = max(apparent_age, age_value);

response_delay = response_time - request_time;

corrected_initial_age = corrected_received_age + response_delay;

resident_time = now - response_time;

current_age = corrected_initial_age + resident_time;

где

Если кэш получает значение большее, чем значение наибольшего положительного целого, с которым он может работать, либо при переполнении во время вычисления Age, он должен передать поле Age со значением 2147483648 (2 ^ 31). Поле Age должно присутствовать в каждом ответе.

5.12.7. Allow

Поле заголовка Allow содержит список методов, поддерживаемых для ресурса, указанного в Request-URI. Поле заголовка Allow должно присутствовать в ответе 501.

Например:

Allow: GET, HEAD, PUT

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

5.12.8. Authorization

Клиент, которому необходимо идентифицироваться, - обычно после ответа 401 (п. 4.4.2, табл. 1), - может выполнить процедуру идентификации, включив заголовок ответа поля Authorization. Содержимое поля Authorization состоит из информации, идентифицирующей права клиентского агента на область запрашиваемых им ресурсов.

Authorization = «Authorization» «:» credentials

5.12.9. Cache-Control

Общее поле Cache-Control используется для определения директив, которым должны подчиняться все кэши в цепочке запрос/ответ.

Директивы должны передаваться через прокси или шлюз вне зависимости от того, имеют ли они для данного прокси или шлюза какое-либо значение.

5.12.10. Connection

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

Перед тем, как направить сообщение с полем Connection, для каждого маркера connection-token в данном поле сервер должен удалить поле (поля) заголовка с соответствующим именем.

Специальный маркер «close» является сигналом закрытия соединения после выполнения данного запроса.

Приложения HTTP версии 1.1, которые не поддерживают стойкие соединения, должны включать маркер «close» в каждое сообщение.

5.12.11. Content-Base

Поле заголовка сущности Content-Base может использоваться для идентификации базового URI, используемого совместно с относительными URL внутри сущности.

Если поле Content-Base отсутствует, базовый URI сущности определяется либо ее полем Content-Location (если Content-Location URI - это абсолютный URI), либо URI, использованным для инициирования запроса.

5.12.12. Content-Encoding

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

Content-Encoding:: = «Content-Encoding» «:» 1#content-coding

Если было применено несколько кодирований, они должны быть перечислены в порядке, в котором они применялись.

5.12.13. Content-Language

Поле заголовка сущности Content-Language описывает естественный язык информации в теле сущности.

Content-Language:: = «Content-Language» «:» 1#language-tag

5.12.14. Content-Length

Поле заголовка сущности Content-Length указывает на размер тела сообщения, в октетах. В случае метода HEAD поле заголовка содержит размер тела сообщения, которое могло бы быть послано клиенту в случае использования метода GET.

Content-Length:: = «Content-Length» «:» 1*DIGIT

5.12.15. Content-Location

Поле заголовка сущности Content-Location может быть использовано для указания местоположения ресурса для сущности.

5.12.16. Content-MD5

Поле заголовка сущности Content-MD5, в соответствии с RFC 1864 [25], содержит контрольный код MD5 для тела сущности, обеспечивая проверку целостности сообщения «из конца в конец».

5.12.17. Content-Range

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

5.12.18. Content-Type

Поле заголовка сущности Content-Type указывает на тип информации тела сущности.

Content-Type:: = «Content-Type» «:» media-type

5.12.19. Date

Поле заголовка сущности Date представляет дату и время генерации сообщения.

Date:: = «Date» «:» HTTP-date

Данное поле должно быть включено во все ответы.

5.12.20. ETag

Поле заголовка сущности ETag определяет тег сущности для размещенной сущности.

ETag:: = «ETag» «:» entity-tag

Например:

ETag: «xyzzy»

ETag: W/»xyzzy»

ETag: ««

5.12.21. Expires

Поле заголовка сущности Expires указывает дату и время, после который данный ответ будет считаться устаревшим. Формат этого поля должен соответствовать RFC 1123 [18].

Expires:: = «Expires» «:» HTTP-date

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

5.12.22. From

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

From:: = «From» «:» mailbox

5.12.23. Host

Поле заголовка запроса Host указывает узел Internet и номер порта ресурса, который запрашивается.

Host:: = «Host» «:» host [ «:» port ]

Клиент HTTP версии 1.1. должен включать поле Host во все запросы. Если поле Host отсутствует, прокси должен добавить это поле.

Сервер HTTP версии 1.1. должен отвечать сообщением 400 при получении запроса с отсутствующим полем Host.

5.12.24. If-Modified-Since

Поле заголовка запроса If-Modified-Since используется с методом GET, чтобы сделать его условным: если запрошенный вариант не был изменен с указанного времени, сущность не будет возвращена. Вместо этого будет возвращен ответ 304.

If-Modified-Since:: = «If-Modified-Since» «:» HTTP-date

Если формат даты неправильный, сервер должен выдать ответ на обычный (не условный) GET.

5.12.25. If-Match

Поле заголовка запроса If-Match используется вместе с методом, позволяющим сделать его условным. Клиент, у которого есть одна или более ранее полученных сущностей, может проверить, является ли одна из них текущей версией, включив соответствующий список тегов сущностей в данное поле. Значение «*» обозначает любую текущую сущность.

Если хотя бы один тег сущностей совпадает с тегом сущности, которая могла бы быть возвращена на подобный безусловный запрос GET, либо если стоит символ «*» и существует текущая версия данного ресурса, тогда сервер может выполнить запрошенный метод.

Сервер должен использовать сильную функцию сравнения.

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

5.12.26. If-None-Match

Поле заголовка запроса If-None-Match используется с методом, чтобы сделать его условным. Использование данного поля подобно полю If-Match.

Если ни один из тегов сущностей не совпадает с тегом сущности, которая могла бы быть возвращена на подобный безусловный запрос GET, либо если стоит символ «*» и не существует текущая версия данного ресурса, тогда сервер может выполнить запрошенный метод.

If-None-Match:: = «If-None-Match» «:» («*» 1#entity-tag)

5.12.27. If-Range

Если у клиента есть в кэше частичная копия сущности, и он хочет получить актуальную целую сущность в свой кэш, он может использовать условный GET с полем If-Range.

If-Range:: = «If-Range» «:» (entity-tag HTTP-date)

Данный запрос будет означать: если сущность не изменилась, отправьте недостающую часть. В противном случае, отправьте целую сущность. Таким образом, сервер должен выдать ответ 206 либо 200.

5.12.28. If-Unmodified-Since

Поле заголовка запроса If-None-Match используется с целью сделать его условным. Если запрошенный ресурс не был изменен с указанного времени, сервер должен выполнить запрошенную операцию так, как если бы поле If-Unmodified-Since отсутствовало.

If-Unmodified-Since:: = «If-Unmodified-Since» «:» HTTP-date

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

5.12.29. Last-Modified

Поле сущности Last-Modified указывает дату и время, в которое, по сведениям сервера-источника, данный вариант был изменен последний раз.

Last-Modified:: = «Last-Modified» «:» HTTP-date

5.12.30. Location

Поле ответа Location используется для перенаправления получателя на иной адрес, чем Request-URI для выполнения запроса или идентификации нового ресурса. Для ответа 201 в данном поле указывается новый созданный ресурс. Для ответов 3хх Location указывает на URL для автоматического перенаправления.

Location:: = «Location» «:» absoluteURI

5.12.31. Max-Forwards

Данное поле запроса может использоваться с методом TRACЕ для ограничения числа прокси или шлюзов, которые могут направлять запрос.

Max-Forwards:: = «Max-Forwards» «:» 1*DIGIT

Значение поля представляет собой десятичное число, показывающее остающееся число разрешенных пересылок сообщения.

Прокси, получивший запрос с полем Max-Forwards = 0, не должен направлять данное сообщение, а должен выдать ответ 200.

5.12.32. Pragma

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

Директивы Pragma должны передаваться без изменения через прокси или шлюз, вне зависимости от их значения для данного прокси или шлюза.

5.12.33. Proxy-Authenticate

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

Proxy-Authenticate:: = «Proxy-Authenticate» «:» challenge

5.12.34. Proxy-Authorization

Поле заголовка запроса Proxy-Authorization позволяет клиенту идентифицировать самого себя и пользователей. Значение поля состоит из мандатов, содержащих идентифицирующую информацию о клиенте для прокси и (или) пространство запрашиваемого ресурса.

Proxy-Authorization:: = «Proxy-Authorization» «:» credentials

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

5.12.35. Public

Поле заголовка Public ответа содержит перечень методов, поддерживаемых сервером. Данное поле может использоваться совместно с полем Allow, которое в свою очередь перечисляет методы, применимые для конкретного Request-URI.

Public:: = «Public» «:» 1#method

Данное поле применимо только к серверу, имеющему непосредственное соединение с клиентом.

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

5.12.36. Range

5.12.36.1. Диапазоны байтов

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

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

где

first-byte-pos - смещение первого байта диапазона,

last-byte-pos - смещение последнего байта в диапазоне. Диапазон определяется от поля first-byte-pos до last-byte-pos включительно. Смещение отсчитывается от нулевого байта сущности.

Получатель неправильно определенного диапазона должен его игнорировать.

С помощью поля suffix-byte-range-spec можно указать N последних байтов сообщения.

При превышении значением suffix-byte-range-spec длины сущности, диапазон определяет всю сущность.

5.12.36.2. Запросы на получение диапазона

Запрос на получение диапазона должен использовать условный или безусловный метод GET. Для определения диапазона используется поле заголовка запроса Range.

Range:: = «Range» «:» ranges-specifier

При выдаче успешного ответа на запрос с определенным диапазоном сервер должен использовать ответ 206.

5.12.37. Referer

Поле заголовка запроса Referer позволяет клиенту указать адрес (URI) ресурса, от которого был получен Request-URI.

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

Referer:: = «Referer» «:» (absoluteURI relativeURI)

Например:

Referer: http://wvw.w3.org/hypertext/DataSources/Overview.html

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

Рекомендуется, чтобы клиент имел возможность включать/отключать отправку роля Referer в запросах.

5.12.38. Retry-After

Поле заголовка ответа Retry-After может использоваться с ответом 503 для указания того, насколько долго сервис будет недоступен данному клиенту.

Retry-After:: = «Retry-After» «:» (HTTP-date delta-seconds)

5.12.39. Server

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

Server:: = «Server» «:» 1*(product comment)

Прокси не должен изменять заголовок Server при направлении ответа.

Прокси может включить поле Via для идентификации самого себя в качестве прокси, направившего ответ.

5.12.40. Transfer-Encoding

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

5.12.41. Upgrade

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

Upgrade:: = «Upgrade» «:» 1#product

Ответ 101 с полем Upgrade должен быть первым ответом сервера после переключения на альтернативный протокол по запросу клиента с полем Upgrade.

Согласование протокола с использованием поля Upgrade применимо только для текущего соединения транспортного уровня.

Поле заголовка Upgrade должно использоваться внутри поля заголовка Connection.

5.12.42. User-Agent

Поле заголовка запроса User-Agent содержит информацию о программном обеспечении клиента, выдавшего запрос. Клиенты не обязательно должны включать данное поле в запрос.

User-Agent:: = «User-Agent» «:» 1*(product comment)

5.12.43. Vary

Поле заголовка ответа Vary используется сервером, чтобы сигнализировать, что сущность, содержащаяся в ответе, была выбрана из ряда доступных представлений с использованием механизма управляемого сервером согласования содержимого. Перечень полей, содержащихся в данном поле, указывает на размерность варьирования представления ресурса. Символ «*» указывает на то, что размерность варьирования не определена.

Vary:: = «Vary» «:» («*» 1#field-name)

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

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

Если кэш получает запрос, Request-URI которого определяет одну или более содержащих поле Vary позиций кэша, он не должен использовать эти позиции кэша, если только в запросе не присутствуют все поля, перечисленные в поле Vary, и содержимое этих полей в запросе не совпадает с содержимым аналогичных полей в позиции кэша.

Сравнение полей заголовка производится без учета конкретного вида разделителей LWS.

5.12.44. Via

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

Если протоколом является HTTP, тогда (и только тогда) received-protocol может не указываться. Вместо настоящего имени узла может указываться псевдоним.

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

По умолчанию port = 80.

Добавление информации в поле Via является необязательным.

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

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

5.12.45. Warning

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

Если в тесте warn-text используется набор символов, отличный от ISO-8859-1 [16], текст должен быть закодирован в соответствии с RFС 2047 [17].

Кэш не должен удалять поля Warning. Но при проверке актуальности позиции кэш должен удалить все поля Warning, ранее присоединенные к данному сообщению. Коды warn-code приведены в табл. 3.

Таблица 3

Коды предупреждений warn-code

5.12.46. WWW-Authenticate

Поле заголовка ответа WWW-Authenticate должно быть включено в сообщение ответа 401 (п. 4.4.2, табл. 1). Значение поля состоит как минимум из одного вызова, указывающего на схему идентификации и параметров, применимых для данного Request-URI.

WWW-Authenticate:: = «WWW-Authenticate» «:» 1#challenge

ПРИЛОЖЕНИЕ 6

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ СРЕДСТВАМ СЛУЖБЫ ДОСТУПА
К ИНФОРМАЦИОННЫМ РЕСУРСАМ ПО ПРОТОКОЛУ NNTP

1. ОБЛАСТЬ ПРИМЕНЕНИЯ

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

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

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

2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К ВЗАИМОДЕЙСТВИЮ КЛИЕНТА NNTP И СЕРВЕРА NNTP

2.1. Соединения

2.1.1. Протокол нижнего уровня

При использовании протоколом NNTP в качестве протокола нижнего уровня TCP, должен использоваться порт 119.

При использовании TCP каждый семибитный символ, передаваемый по соединению TCP должен передаваться в отдельном октете. При этом символ должен быть выровнен вправо, а старший бит октета установлен в 0.

2.1.2. Установление соединения и закрытие соединения

Клиент должен инициировать установление соединения протокола нижнего уровня. После установления соединения сервер должен выдать ответ 200 либо 201.

Закрытие соединения осуществляется в следующей последовательности: клиент выдает команду QUIT, сервер выдает ответ 205, сервер разрывает соединение протокола нижнего уровня.

3. ПЕРЕЧЕНЬ И СТРУКТУРА СООБЩЕНИЙ ПРОТОКОЛА NNTP

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

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

3.1. Команды

3.1.1. Структура команд

Команда должна состоять из кода команды и аргументов. Для ряда команд аргумент не требуется. Слово команды и последующий аргумент, а также аргументы между собой должны быть отделены одним или более символами <SP>.

Различие между строчными и прописными символами в кодах команд и аргументах команд является несущественным.

Каждая команда должна заканчиваться символами <CRLF>.

Длина команды должна быть менее или равна 512 символов, включая все символы <SP>, символы разделителей и <CRLF>. Все команды должны состоять из одной строки.

3.1.2. Список команд

Список команд приведен в табл. 1.

Таблица 1

Список команд

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3.2. Ответы

Ответы делятся на текстовые ответы и ответы статуса.

3.2.1. Текстовый ответ должен состоять из серии текстовых строк. Каждая строка должна заканчиваться символами <CRLF>. Последовательность «<CRLF>.<CRLF>« (0x0D 0х0А 0х2Е 0x0D 0х0А) указывает на конец текстового ответа.

При посылке сервером текстового ответа каждую последовательность «<CRLF>.» (0x0D 0х0А 0х2Е) сервер должен заменять на «<CRLF>..» (0x0D 0х0А 0х2Е 0х2Е). Клиент должен выполнять обратное преобразование. Указатель конца текстового ответа данному преобразованию не подвергается.

3.2.2. Ответ статуса должен состоять из 3-значного кода ответа (передаваемого как три символа), за которым следует текст.

Значения номера ответа первой и второй цифры приведены в табл. 2 и табл. 3.

Таблица 2

Содержание первой цифры ответа

Таблица 3

Содержание второй цифры ответа

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

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

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]):

ПРИЛОЖЕНИЕ 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 клиента.

Инициировать изменение портов, отличных от установленных по умолчанию, может только 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.

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

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

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

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

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

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

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

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

n байт данных

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

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

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

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

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. Структуры данных.

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

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

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

Структура 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>. He должно делаться различия между прописными и строчными буквами как в команде, так и в аргументе.

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

Таблица 1

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

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>.

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

первая цифра

вторая цифра

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

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

Таблица 2

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

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

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

Таблица 3

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

6. СИНТАКСИС КОМАНД FTP

USER <SP> <username> <CRLF>

PASS <SP> <password> <CRLF>

ACCT <SP> <account-information> <CRLF>

CWD <SP> <pathname> <CRLF>

CDUP <CRLF>

SMNT <SP> <pathname> <CRLF>

QUIT <CRLF>

REIN <CRLF>

PORT <SP> <host-port> <CRLF>

PASV <CRLF>

TYPE <SP> <type-code> <CRLF>

STRU <SP> <structure-code> <CRLF>

MODE <SP> <mode-code> <CRLF>

RETR <SP> <pathname> <CRLF>

STOR <SP> <pathname> <CRLF>

STOU <CRLF>

APPE <SP> <pathname> <CRLF >

ALLO <SP> <decimal-integer>

[<SP> R <SP> <decimal-integer>] <CRLF>

REST <SP> <marker> <CRLF>

RNFR <SP> <pathname> <CRLF>

RNTO <SP> <pathname> <CRLF>

ABOR <CRLF>

DELE <SP> <pathname> <CRLF>

RMD <SP> <pathname> <CRLF>

MKD <SP> <pathname> <CRLF>

PWD <CRLF>

LIST [<SP> <pathname>] <CRLF>

NLST [<SP> <pathname>] <CRLF>

SITE <SP> <string> <CRLF>

SYST <CRLF>

STAT [<SP> <pathname>] <CRLF>

HELP [<SP> <string>] <CRLF>

NOOP <CRLF>

Определения аргументов команд

<username>:: = <string>

<password>:: = <string>

<account-information>:: = <string>

<string>:: = <char> <char><string>

<char>:: = любой из 128 символов ASCII кроме <CR> and <LF>

<marker>:: = <pr-string>

<pr-string>:: = <pr-char> <pr-char><pr-string>

<pr-char>:: = печатные символы, любой код ASCII от 33 до 126

<byte-size>:: = <number>

<host-port>:: = <host-number>,<port-number>

<host-number>:: = <number>,<number>,<number>,<number>

<port-number>:: = <number>,<number>

<number>:: = любое десятичное целое от 1 до 255

<form-code>:: = N Т С

7. ДИАГРАММЫ СОСТОЯНИЙ

7.1. Команды ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, NOOP, PASV, QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, TYPE.

Диаграмма состояний сервера FTP для команд ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, NOOP, PASV, QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, TYPE приведены на рис. 4.

Используемые обозначения:

В - Начало

W - Ожидание

S - Успешное выполнение

F - Восстановимая ошибка

Е - Невосстановимая ошибка

Рис. 4. Диаграмма состояний сервера FTP для команд ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, NOOP, PASV, QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, TYPE

7.2. Команды APPE, LIST, NLST, REIN, RETR, STOR, STOU

Диаграмма состояний сервера FTP для команд APPE, LIST, NLST, REIN, RETR, STOR, STOU приведены на рис. 5.

Используемые обозначения:

В - Начало

W - Ожидание

S - Успешное выполнение

F - Восстановимая ошибка

Е - Невосстановимая ошибка

Рис. 5. Диаграмма состояний сервера FTP для команд АРРЕ, LIST, NLST, REIN, RETR, STOR, STOU

7.3. Команды RNFR и RNTO

Диаграмма состояний сервера FTP для команд RNFR и RNTO приведены на рис. 6.

Используемые обозначения:

В - Начало

W - Ожидание

S - Успешное выполнение

F - Восстановимая ошибка

Е - Невосстановимая ошибка

М - Среднее состояние

Рис. 6. Диаграмма состояний сервера FTP для команд RNFR и RNTO

7.4. Команда REST

Диаграмма состояний сервера FTP для команды REST приведена на рис. 7.

Используемые обозначения:

В - Начало

W - Ожидание

S - Успешное выполнение

F - Восстановимая ошибка

Н - Невосстановимая ошибка

М - Среднее состояние

Обозначения: команда - АРРЕ, STOR или RETR

Рис. 7. Диаграмма состояний сервера FTP для команды REST

7.5. Команды USER, PASS, ACCT

Диаграмма состояний сервера FTP для команд USER, PASS, ACCT приведена на рис. 8.

Используемые обозначения:

В - Начало

W - Ожидание

S - Успешное выполнение

F - Восстановимая ошибка

Е - Невосстановимая ошибка

М - Среднее состояние

Рис. 8. Диаграмма состояний сервера FTP для команд USER, PASS, ACCT

СОДЕРЖАНИЕ