| Network Working Group Brian Kantor (U.C. San Diego) Request for Comments: 977 Phil Lapsley (U.C. Berkeley) February 1986 Network News Transfer Protocol Перевод Дмитрия Есакова. АО Релком. При копировании ссылка на источник обязательна. (http://nntp.mv.ru/DOC/RFC977rus.txt) Просьба направлять замечания по переводу на esakov@relcom.eu.net Предложенный стандарт для потоковой передачи новостей. Статус этой памятки NNTP специфицирует протокол для распространения, запросов, поиска, и отправки статей новостей, использующий надежную потоковую передачу новостей по ARPA-Internet сообществу. NNTP разработано так, что статьи новостей хранятся в центральной базе, позволяя подписчику выбирать только те статьи, которые он хочет прочитать. Индексирование, перекрестные ссылки, и удаление устаревших новостей (expiration) также предусмотрено. Этот RFC предлагает протокол для ARPA-Internet сообщества, и запрашивает идеи и пожелания для совершенствования. Распространение этой памятки неограничено. 1. Введение Много лет ARPA-Internet сообщество поддерживало распространение биллютеней, информации и данных в своевременной форме тысячам участников. Мы называем такие частицы информации новостями. Такие новости позволяют своевременно распространять такие новости по интересам, как исправления ошибок в программах (bug fixes), обзоры новых продуктов, технические подсказки (technical tips) и подсказки по программированию, также как и горячие обсуждения по делам работающих профессионалов-копьютерщиков. Новости очень популярны среди их читателей. Популярны 2 метода распрострранения таких новостей: интернетовский метод прямой рассылки и система новостей USENET. 1.1 Интернетовские списки рассылки (mailing lists). Интернет-сообщество рспространяет новости используя списки рассылки. Существуют списки адресов почтовых ящиков подписчиков и пересылочных подсписков всех заинтересованных получателей. Эти списки рассылки работают путем пересылки отправленной информации кахдому подписчику списка рассылки. Такая пересылка непроизводительна, когда лист вырастает до дюжины и более людей, поскольку пересылка отдельной копии каждому подписчику использует большое количество пропускной способности сети, ресурсов CPU и значительное количество дискового пространства на хосте-получателе. Также существует значительная проблема поддержки самого списка рассылки: подписчики переходят от одной темы к другой; новые подписчики присоединяются, а старые уходят; да и хосты появляются и исчезают. 1.2 Система новостей USENET. Очевидно, что заслуживающее внимания снижение использования этих ресурсов может быть достигнуто если статьи хранятся в центральной базе данных на получающем хосте, вместо того, чтобы хранится в каждом почтовом ящике. Система новостей USENET предлагает именно этот метод. Существует центральное хранилище статей новостей в одном месте (обычно некоторая буферная директория) и набор программ, который позволяет подписчику выбирать именно те сообщения, которые он хочет прочитать. Индексирование, перекрестные ссылки, и удаление устаревших новостей (expiration) также предусмотрено. 1.3 Центрально хранилище новостей Для группы хостов, соединенных вместе быстрой LAN (такой как Ethernet), это даже имеет еще больше смысла об'единить распространение новостей на одном (или нескольких) хостах, и разрешить доступ к этим статьям используя модель клиент-сервер. Подписчики могут запрашивать только те статьи, которые они хотят увидеть, без необходимости расточительно копировать каждую статью на каждый хост. 1.4 Центральный сервер новостей Путь к достижению экономии, это иметь центральную компьютерную систему, которая сможет обеспечить услуги новостей другим системам в локальной сети. Такой сервер будет управлять совокупностью статей и индексировать файлы для каждого, кто захочет почитать новости по локальной сети. Для большой группы компьютерных систем экономия дискового пространства будет несомненно значительна. Также, это позволяет рабочим станциям с ограниченным дискового пространством поучаствовать в новостях без приходящих на них сообщений, расходующих дефицитное место на дисках. Мы слышали о некоторых удачных попытках предоставлять централизованные услуги новостей используя IBIS и другие разделяемые или распределенные файловые системы. В то время как это возможно, что такие реализации распределенных файловых систем должны хорошо работать с группой сходных компьютеров, использующих почти идентичные операционные системы, такая схема обычно недостаточна, чтобы предлагать услуги большому разнообразию клиентских систем, особенно когда много разнообразных операционных систем может использоваться среди группы клиентов. Существует не много (если вообще есть) разделяемых сетевых файловых систем, которые могут предложить применимый ко всем сервис, который обслуживает соединения, используя интернетовский TCP, особенно когда рассматривается большое количество разнообразного аппаратного обеспечения и ОС хостов. NNTP специфицирует протокол для распространения, запросов, поиска, и отправки статей новостей, используя надежный поток (такой как TCP) клиент-серверной модели. NNTP спроектирован так, что статьи новостей должны храниться только в одном (предположительно центральном) хосте, и пользователи на других хостах, соединенных с LAN, могли читать новости использую потоковое соединение к серверу новостей. 1.5 Промежуточные сервера новостей Для группы машин с большим количеством пользователей (как может быть в случае университета или большой сети на предприятии) может использоваться промежуточный сервер. Этот промежуточный, или "slave", сервер работает на любой компьютерной платформе, и отвечает за промежуточные запросы на чтение новостей и выполняет локальное кэширование часто запрашиваемых сообщений. Обычно, клиент, пытающийся получить сервис новостей, сначала пытается соединится с портом новостей на локальной машине, если эта попытка была неудачна, указывая на неработающий сервер, система может либо отказать к доступу к новостям, либо рзрешить соединение с центральным master-сервером новостей. Для рабочих станций или других малых систем, прямая связь с master-сервером возможно будет нормальным способом работы. Эта спецификация не рассматривает работу slave NNTP сервера. Мы просто высказываем мнение, что slave-сервера - логичное дополнение к использованию NNTP сервера, которое улучшит работу в большой LAN. 1.6 Распространение новостей NNTP имеет команды, которые предусматривают прямой метод обмена статьями между сотрудничающими хостами. Хосты, которые хорошо соединены с локальными или другими быстрыми сетями и которые захотят получить копию статей для локального хранения, найдут NNTP более эффективным методом для распространения новостей, чем более традиционные методы передачи (такие как UUCP). В традиционном методе распространения новостей, статьи распространяются от хоста к хосту потоком (feed), т.е. каждый хост будет посылать все новые статьи каждому хосту, которого он снабжает статьями. Ясно, что посылая статьи, которые хост уже получил от третьего хоста (многие хосты, которые получающие новости, имеют несколько связей)повторно, является расходованием времени и коммуникационных ресурсов, но для транспортного механизма, который основан единичных транзакциях, нежели на диалоговых (таких как UUCP в мире UNIX), время распространения уменьшается путем посылки всех статей, заставляя получающий хост уничтожать дубликаты. Это особенно верно, когда количество сессий ограничено разом в день. Используя NNTP, хосты, обменивающиеся статьями имеют диалоговый механизм для решения какие из статей надо посылать. Хост, желающий получить новые статьи, или который имеет новые статьи для отправки, будет обычно контактировать с одним или несколькими своими соседями, используя NNTP. Сначала он будет узнавать, не появились-ли новые группы на обслуживающем его хосте путем команды NEWGROUPS. Если да, и они подходят или желаемы (как установлено правилами на локальном хосте), то эти новые группы будут созданы. Клиентский хост, затем, будет запрашивать, какие новые статьи для групп, которые он желает получать, пришли, используя команду NEWNEWS. Он получит список новых статей от сервера, и сможет запросить передачу тех статей, которые он желает и еще не имеет. Наконец, клиент может сообщить серверу о статьях, которые он недавно получил. Сервер пометит статьи, копии которых он уже получил, и которые должны быть отправлены, чтобы добавить их в коллекцию. Таким образом, передаются статьи, которые желательны и не дублицированы. 2. Спецификация NNTP 2.1 Обзор Сервер новостей, специфицированный этим документом, использует потоковую соединения (такуб как TCP) и SMTP-подобные команды и ответы. Он спроектирован принимать соединения от хостов и предоставлять простой интерфейс к базе данных новостей. Этот сервер является только интерфейсом между программами и базой данных новостей. Он не выполняет никакого взаимодействия с пользователем или функций уровня представления (OSI). Эти "дружественные пользователю" функции лучше предоставлены клиентским программам, которые имеют лучшее понимание среды, в которой они работают. При использовании через интернетовский TCP для этого сервиса присвоен 119 контактный порт. 2.2 Символьные коды Команды и ответы составлены из кодов таблицы ASCII. Когда транспортный сервис обеспечивает 8-ми битный канал передачи, каждый 7-ми битный символ выравнивается в октет со старшим битом 0. 2.3 Команды Команды состоят из командного слова, за которыми в некоторых случаях могут следовать параматры. Команды с параметрами должы отделять параметры друг от друга и от команды одним или несколькими пробелами или символами табуляции. Командная строка должна быть завершена со всеми необходимыми параметрами и не может содержать более одной команды. Команды и параметры команды не учитывают регистра. То есть, команда или параметр могут быть в верхнем регистре, нижнем регистре или любой смесью их символов верхнего или нижнего регистра. Командная строка должна завершаться парой CR-LF (Carriage Return - Line Feed). Командная строка не должна превышать 512 символов в длину, считая все символы, включая пробелы, разделители, пунктуацию и завершающие CR-LF (поэтому для командной строки с параметрами допускается максимальная длина 510 символов). Поддержка более длинных командных строк не оказыватся. 2.4 Ответы Существуют два вида ответов: текстовые и статусные. 2.4.1 Текстовые ответы Текст посылается после того как послана строка числового статусного ответа, что означает что текст пойдет следом. Текст посылается в виде последовательных строк в текстовой манере, каждая завершается парой CR-LF. Одиночная строка содержащая только точку посылается, чтобы указать на конец текста (т.е. сервер пошлет пару CR-LF в конце последней строки текста, точку и еще одну пару CR-LF). Если текст содержит точку как первый сивол текста в оригинале, эта первая точка удваивается. Поэтому клиент должен проверять первый символ каждой получаемой строки, и для начинающихся с точки определять, или это конец текста, или обрезать двойную точку в одинарную. Намерение таково, что текстовые сообщения обычно будут высвечиваться на пользовательском терминале, тогда как командно-статусные ответы будут интерпретироваться клиентской программой перед тем как возможные сообщения будут выведены. 2.4.2 Статусные ответы (отчеты о состоянии) Существуют статусные отчеты от сервера, и ответы на последнюю команду, полученную от клиента. Строки отчета о состоянии начинаются с 3-х циферного численного кода, который достаточен для различения всех ответов. Некоторые их них могут возвещать последующую передачу текста. Первая цифра ответа общо показывает успех, неудачу или продвижение выполнения пред'идущей команды. 1xx - Информационное сообщение 2xx - Команда ok 3xx - Команда ok, соотв. шлите продолжение. 4xx - Команда верна, но не может быть выполнена по каким-то причинам. 5xx - Команда не пред'усмотрена, или не верна, или произошла серьезная програмная ошибка. Следующая цифра кода показывает категорию функциональных ответов. x0x - Сообщение о соединении, установке или смешанное сообщение x1x - Выбор группы новостей x2x - Выбор статьи x3x - Функции распространения x4x - Отправка (posting) x8x - Нестандартные расширения (частные реализации) x9x - Отладочное сообщение Точные коды ответов, которые должны ожидаться от каждой команды детализированы в описании этих команд. В дополнение ниже приводится общий список кодов ответа. Конкретные статусные ответы содержат такие параметра как номера и имена. Номер и тип такого параметра фиксирован для каждого кода ответа для упрощения интерпретации этих ответов. Параметры отделены от численного кода ответа и друг от друга одним пробельным символом. Все численные параметры десятичны и могут иметь первым символом ноль. Все строчные параметры начинаются после разделяющего пробела и заканчиваются перед следующим разделяющим пробелом или парой CR-LF в конце каждой строки. (Строчные параметры, следовательно, не могут содержать пробелы.) Весь текст (если он есть) в ответе, который не является параметром ответа, должен следовать и быть отделенным от других параметров пробелом. Также, учтите, что текст, следующий за кодом ответа, может варьироваться в различных раализациях сервера. Трехзначный код должен использоваться для определения, что ответ был отправлен. Коды ответа, не специфицированные в этом стандарте, могут использоваться для любых специфических настроек дополнительных команд, также не специфицированных. Это должно быть выбрано для приспособления к шаблону "x8x", специфицированному выше. (Учтите, что отладка для ясности предусмотрена в кодах ответа "x9x.) Использование неспецифицированных кодов ответа для стандартных команд запрещено. Мы заготовили ответ по шаблону x9x для отладки. Так как многое из вывода данных отладки может классифицировться как "информационное сообщение", мы будем, следовательно, предполагать, что ответы от 190 до 199 будут использоваться для вывода разнообразных данных отладки. Требования по выводу данных отладки в этой спецификации отсутствуют, но если таковые предусмотрены при соединения, они должны использовать коды ответа. Другие x9x коды могут использоваться для отладки в специфических реализациях. (К примеру, может использоваться код 290 для подтверждения удаленного запроса отладки.) 2.4.3 Общие ответы Нижеперечисленное - это список общих кодов ответа, которые могут посылаться NNTP сервером. Здесь нет привязки к каким-то командам, но может выводиться в результате установления соединения, сбоя, или некоторых других необычных условий. Вообще, коды типа 1xx могут игнорироваться или высвечиваться по желанию; коды 200 или 201 посылаются при первоначальной установке связи с NNTP сервером в зависимости от разрешения постинга; код 400 будет послан, когда NNTP сервер прекращает сервис (к примеру, по запросу оператора); и код 5xx показывает, что команда не может быть выполнена по необычным причинам. 100 вспомогательный текст от 190 до 199 вывод отладочных сообщений 200 сервер готов - постинг разрешен 201 сервер готов - постинг запрещен 400 сервис прекращен 500 команда не опознается 501 синтаксис команды неверен 502 доступ ограничен или нет доступа 503 програмная ошибка - команда не выполнена 3. Детали команд и ответов На следующих страницах описывается каждая команда, опознаваемая NNTP сервером и ответы, которые будут выведены на эти команды. Каждая команда, для ясности, показана в верхнем регистре, хотя регистр игнорируется в интерпретации команды NNTP сервером. Все параметры показаны в нижнем регистре. Параметр, указанный в [квадратных скобках] не обязателен. На пример, [GMT] означает, что сочетание букв GMT может присутствовать, или быть опущенным. Каждая команда, описаная в этом разделе, должна быть реализована во всех NNTP серверах. Никаких ограничений на добавление новых команд нет; однако, мы рекомендуем, чтобы любые неспецифицированные команды начинались с буквы ""X", чтобы избежать конфликта с последующими исправлениями этой спецификации. Разработчикам напоминаем, что такие дополнительные команды не могут переназначать специфицированные коды ответа о состоянии. Использование дополнительных неспецифицированных ответов на стандартные команды также запрещено. 3.1 Команды ARTICLE, BODY, HEAD и STAT Существует 2 формы команды ARTICLE (и смежных BODY, HEAD, и STAT), каждый использует различный метод указания, какая статья должна быть найдена. Когда за командой ARTICLE следует идентификатор статьи в угловидных скобках ("<" и ">"), используется первая форма команды; когда команда снабжена численным параметром, или идет без параметра - применяется вторая форма. Текст статьи выводится в виде текстового ответа, как описано в этом документе выше. Команды HEAD и BODY идентичны команде ARTICLE, кроме того, что возвращается только строки заголовка или тела сообщения соответственно. Команда STAT близка команде ARTICLE, за исключением того, что никакой текст не выводится. Когда сообщение выбирается по номеру в группе, команда STAT служит для установки текущего указателя статьи без отправки текста. Ответ подтверждения будет содержать идентификатор статьи, который может иметь некоторое значение. Использование команды STAT для выбора по идентификатору статьи допустимо, но ценность этого под вопросом, так как выбор по идентификатору статьи не изменяет положения "указателя текущей статьи". 3.1.1 ARTICLE (выбор по идентификатору статьи) ARTICLE <идентификатор статьи> Выводит заголовок, пустую строку, а затем тело выбранного сообщения. Идентификатор статьи - идентификатор статьи как он выглядит в заголовке сообщения. Предусотрено, что клиент получит идентификатор статьи из списка, предоставленного командой NEWNEWS, из указателя, содержащегося внутри другой статьи, или от идентификатора статьи, предоставленного в ответе какой-либо иной команды. Просьба учитывать, что внутренне-установленный "указатель текущей статьи" не изменяется этой командой. Это и для способствованию представления статьи, на которую ссылается уже прочитанная статья, и из-за семантической сложности определения правильной последовательности и членства статьи, которая может быть отправлена больше чем в одну группу. 3.1.2 ARTICLE (выбор по номеру) ARTICLE [nnn] Показывает заголовок, пустую строку, затем тело текущей или указанной статьи. Необязательный параметр nnn - это численний идентификатор статьи в текущей группе, и должен выбираться из диапазона статей, предоставленного, когда выбрана группа. Если это опущено, подразумевается текущая статья. Внутренне-установленный "указатель текущей статьи" устанавливается этой командой, когда указан верный номер статьи. [Нижеследующее применимо к обоим формам команды ARTICLE.] Ответ, показываюший текущий номер статьи, строка идентификатора статьи, и следующий за этим текст будет выведен. Выведенная строка идентификатора статьи - это идентификационная последовательность символов, содержащаяся в треугольных скобках, которая извлекается из заголовка самой статьи. Строка заголовка, идентификатор статьи, (требуется по RFC 850) должна быть использована как источник этой информации. Если строка заголовка (идентификатор) отсутствует, в угольные скобки должна быть взята цифра "0". Так как поле идентификатора статьи уникально для каждой статьи, оно может быть использовано программой для чтения новостей для пропуска статей-дубликатов, которые отправлены более одного раза или в более чем одну группу. 3.1.3 Ответы 220 n <a> статья найдена - заголовок и тело сообщения последуют (n = номер статьи, <a> = идентификатор статьи) 221 n <a> статья найдена - заголовок последует 222 n <a> статья найдена - тело сообщения последует 223 n <a> статья найдена - запросите текст отдельно 412 не выбрана группа 420 не выбрано текущее сообщение 423 такой номер статьи отсутствует в этой группе 430 статья не найдена 3.2 Команда GROUP 3.2.1 GROUP GROUP ggg Необходимый параметр ggg - это имя группы, которая должна быть выбрана (к примеру "net.news"). Список существующих групп может быть получен по команде LIST. По команде GROUP выведется ответ об успешном выборе выведет номера первой и последней статьи в группе и оценку количества статей в этой группе. Нет необходимости, чтобы оценка была верна, тем не менее это полезно; она должна быть только такая же или больше, чем реальное количество статей. (Некоторые реализации будут фактически посчитывать количество статей. Другие будут просто вычитать номер первой из номера последней для нахождения их количества). Когда допустимая группа выбрана методом этой команды, внутренне-установленный "указатель текущей статьи" выставляется на первую статью группы. Если указана несуществующая группа, то пред'идущая группа и статья заменяют выбранную. Если выбрана пустая группа, то "указатель текущей статьи" находится в неопределенном состоянии, и не должен использоваться. Учтите, что имя группы независит от регистра. Или оно должно быть тождественно группе, взятой от команды LIST, или последует ошибка. 3.2.2 Ответы 211 n f l s группа выбрана (n = расчетное количество статей в группе, f = номер первой статьи в группе, l = номер последней статьи в группе, s = имя группы 411 нет такой группы 3.3 Команда HELP 3.3.1 HELP HELP Предоставляет короткое описание команд, которые воспринимаются этой реализацией сервера. Текст помощи, будет представлен как вывод текста, завершенный пустой строкой с одной точкой. 3.3.2 Ответы 100 текст помощи следует 3.4 Команда IHAVE 3.4.1 IHAVE IHAVE <идентификатор статьи> Команда IHAVE информирует сервер, что у клиента есть статья, идентификатор которой <идентификатор статьи>. Если сервер запрашивает копию этой статьи, он выведет ответ, инструктирующий клиента отправить эту статью. Если серверу не нужна эта статья (если, к примеру, у сервера уже есть ее копия), выведется ответ, что статья не нужна. Ежели запрашивается передача статьи, клиент должен послать эту статью, включая заголовок и тело, способом, определенным для передачи текста от сервера. И будет выведен код ответа, показывающий удачу или сбой передачи. Назначение этой команды отличается от команды POST тем, что она предназначена для использования в случае передачи уже отправленных статей между серверами. Обычно она не будет использоваться, когда клиентом является обычная программа для чтения новостей. В особенности, эта функция вызовет программу отправки новостей сервера с соответствующими настройками (флаги, опции, и т.д.), чтобы показать, что последующее сообщение передается от другого хоста. Сервер может, тем не менее, выбрать не посылать сообщение, если после последующей проверки статьи он посчитает это нежелательным. 436 или 437 коды об ошибке могут быть выведены, что подходит в этой ситуации. Основание для такого последующего отказа от статьи, может включать такие проблемы, как несоответствующая группа или область распространения, ограничения дискового пространства, длина статьи, испорченный заголовок, и т.п. Это типичные ограничения, установленные программами сервера и не необходимо для самого NNTP. 3.4.2 Оттветы 235 статья передана успешно 335 послать статью, предназначенную к передаче. Оканчивается <CR-LF>.<CR-LF> 435 статья нежелаттельна - не посылать ее 436 сбой передачи - попробуйте повторить позже 437 статья отклонена - не пробуйте повторять Замечания для разработок: Из-за того, что програмное обеспечение некотторых серверов новостей может не иметь возможности немедленно решать, что статья нежелательна для отправления или пересылки, приемлимо сообщить об успешной передаче, и позже молча отбросить ее. Таким образом, резрешено вывести код подтверждения 235 и затем отбросить полученную статью. Это не является полностью приемлимым решением проблемы. Возможно, некоторые реализации захотят послать почтовое сообщение автору статьи в некоторых их таких случаев. 3.5 Команда LAST 3.5.1 LAST LAST По этой команде внутренне установленный "указатель текущей статьи" установливается на пред'идущую статью в текущей группе. Если он уже установлен на первую статью группы, возвращается сообщение об ошибке, и текущая статья заменяет выбранную. Внутренне установленный "указатель текущей статьи" выставляется этой командой. Будет выведен ответ, указывающий номер текущей статьи и последовательность ее идентификатора. 3.5.2 Ответы 223 n a статтья найдена - запросите текст отдельно (n - номер статьи, a - уникальный идентификатор статьи) 412 групппа не выбрана 420 не выбрана текущая статья 422 нет пред'идущих статей в этой группе 3.6 Команда LIST 3.6.1 LIST LIST Выводит список действующих групп и соответствующую информацию. Каждая группа выводится как строка текста, в следующем формате: group last first p где <group> - имя группы, <last> это номер последней известной статьи, находящейся в этой группе, <first> - это номер первой статьи, и флаг <p> - это либо "yes", либо "no", показывающий, разрешен постинг в эту группу (y), или запрещен (n). Поля <first> и <last> всегда численные. Они могут иметь первым символом ноль. Если поле <last> в цифрах меньше поля <first>, то в хранилище группы, в настоящий момент, статей нет. Учтите, что постинг может все еще быть запрещен клиенту, даже если команда LIST показывает, что в конкретную группу постинг разрешен. Для об'яснения клиентских ограничение, смотрите команду POST. Флажок постинга существует для каждой группы, т.к. некоторые группы модерируемые, или они являются дайджестами, и поэтому в них нельзя посылать статьи; это значит, что статьи, посылаемые в них, должны быть отправлены по почте модератору, который отошлет их дальше. Это не зависит от разрешения постинга, данного клиенту NNTP сервером. Просьба учитывать, что пустой лист (т.е. тело текста выводимого этой командой, состоит только из завершающей точки) является возможным допустимым ответом, и показывает, что сейчас нет действительных групп. 3.6.2 Ответы 215 список групп следует 3.7 Команда NEWGROUPS 3.7.1 NEWGROUPS NEWGROUPS date time [GMT] [<distributions>] Будет выведен список групп, созданных с <date and time>, в том же формате, что и по команде LIST. Дата выводится как 6 цифр в формате YYMMDD, где YY это 2 последние цифры года, MM это 2 цифры месяца (с первой цифрой ноль, если необходимо), и DD это число месяца (с первой цифрой ноль, если необходимо). Ближайший век подразумевается как часть года (т.е. 86 означет 1986, 30 означет 2030, 99 - 1999, 00 - 2000). Также должно быть указано время. Оно должно быть в виде 6 цифр HHMMSS, где HH - час в 24-х часовом формате, MM - минуты от 00 до 59, и SS - секунды от 00 до 59. Время подоазумевается во временной зоне, где находится сервер, или выводится метка "GMT", в этом случае и время и дата в значении для нолевого меридиана. Необязательный параметр "distributions", это список групп для распространения, заключенных в угольные скобки. Если указано, часть групп для распространения из числа новых (например 'net' в 'net.wombat') будет проверяться на соответствие категориям распространения, и будут выведены только соответствующие. Если должно быть выведено более одной, они должны быть разделены внутри угольных скобок запятыми. Просьба учитывать, что пустой список (т.е. тело текста выводимого этой командой, состоит только из завершающей точки) является возможным допустимым ответом, и показывает, что сейчас нет новых групп. 3.7.2 Ответы 231 список новых групп следует 3.8 Команда NEWNEWS 3.8.1 NEWNEWS NEWNEWS newsgroups date time [GMT] [<distribution>] Выведется список идентификаторов отправленных или полученных статей со времени "date". Формат списка будет по одному идентификатору статьи на строку, как будто посылается текст. Строка содержащая одну только точку с последующим CR-LF завершит список. Дата и время в том же формате, что и в команде NEWGROUPS. Имя группы, содержащее звездочку ("*"), может использоваться для расширения поиска статьи в нескольких, или всех группах. Звездочка будет расширена для соответствия любой части имени группы (например net.micro* выдаст соответствия с net.micro.wombat, net.micro.apple, etc). Таким образом, если дана только звездочка, как имя группы, поиск новых статей будет осуществляться по всем группам. (Просьба учитывать, что расширение звездочкой "*" является глобальным замещением; в часности, указание, например, net.*.unix должно быть верно расширено, чтобы охватить имена, такие как net.wombat.unix и net.whocares.unix.) И наоборот, если в данном иммени группы нет звездочки, поиск новых статей будет осуществляться только в указанной группе. Имена групп должны выбираться из тех, что выведены в списке доступных групп. В этой команде могут быть указаны несколько имен групп, разделенных запятыми. Никакой запятой не должно появляться после последней группы в списке. [Разработчики, помните об ограничении на длину команды в 512 симмволов!] Восклицательный знак может быть использован, чтобы инвертировать соответствие. Это может использоваться для того, чтобы выборочно пропускать определенные группы из, иначе, большего списка. На пример, указание группы в виде "net.*,mod.*,!mod.map.*", должно указывать, что все net.<anything> и все mod.<anything>, КРОМЕ группы mod.map.<anything> будут соответствовать запросу. Восклицательный знак, если применяется, должен быть первым символом данного имени группы или шаблона. Необязательный парамнтр distributions" - это список распространяемых групп, заключенных в угольные скобки. Если указано, распространяемая часть поля newsgroup в статье (к примеру, 'net' в net.wombat') будет проверяться на соответствие со списком категорий на распространение, и только те статьи, которые имеют как минимум одну группу, принадлежащую к списку на распространение, будут перечислены. Если снабжаться должно более одной группы, они должны быть разделены запятой внутри угольных скобок. Использование команд IHAVE, NEWNEWS, и NEWGROUPS для распротранения новостей, обсуждалось в пред'идущей части этого документа. Просьба учитывать, что пустой список (т.е. тело текста выводимого этой командой, состоит только из завершающей точки) является возможным допустимым ответом, и показывает, что сейчас нет новых статей. 3.8.2 Ответы 230 список новых статей по идентификатору статьи следует. 3.9 Команда NEXT 3.9.1 NEXT NEXT Внутренне установленный "идентификатор текущей статьи" перемещается на следующую статью в текущей группе. Если в группе больше не содержится статей, выводится сообщение об ошибке и текущая статья заменяет выбранную. Этой командой устанавливается внутренне установленный "идентификатор текущей статьи". Будет выведен ответ, указывающий номер текущей статьи и строку идентификатора статьи. В ответ на эту команду текст не посылается. 3.9.2 Ответы 223 n a статья выбрана - запросите текст отдельно (n - номер статьи, a - уникальный идентификатор статьи) 412 не выбрана группа 420 не выбрана текущая статья 421 следующей статьи нет в группе 3.10 Команда POST 3.10.1 POST POST Если постинг разрешен, чтобы показать, что статья, предназначенная для постинга должна отправляться, возвращается код ответа 340. Код ответа 440 показывает, что постинг запрещен по некоторым установочным причинам. Если постинг разрешен, статья должна быть представлена в формате, специфицированном RFC850, и должна включать все необходимые строки заголовка. После того, как заголовок и тело статьи было полностью отправлено клиентом серверу, будет выведен соответствующий код ответа, чтобы показать успех или сбой попытки отправки. Текст, формирующий заголовок и тело статьи, предназначенной для отправки, должен быть послан клиентом, используя соглашение для текста, получаемого от сервера новостей: одна точка (".") в строке означает конец текста, в строках, начинающихся с точки, эта точка должна быть удвоена в процессе передачи. Сервером не должны предприниматься попытки для фильтрации символов, переносить или ограничивать строки, или дргимм образом обрабатывать приходящий текст. Это наша цель, чтобы сервер просто передавал приходящую статью, предназначенную для постинга, программному обеспечению для постинга сервера, которое не входит в эту спецификацию. Смотрите детали в RFC850. Так как большинство серверов будет желать, чтобы клиентская программа разрешала пользователю использовать текстовый редактор для подготовки статьи, и передавать ее серверу для постинга только после того, как она сформмирована, клиентская программа должна принимать во-внимание об'явление , которое приветствует ее, когда соединение устанавливается в первый раз. Это об'явление показывает разрешен или нет клиенту постинг, и может использоваться для пред'упреждения пользователя, что его доступ только для чтения, если это так. Это убережет пользователя от траты драгоценного времени на составление статьи, чтобы убедиться, что постинг его сообщения запрещен. Метод и определение какие клиенты и сервера могут читать и посылать зависит от реализации и не раскрывается этой спецификацией. 3.10.2 Ответы 240 статья отправлена успешно 340 отправляйте статью. оканчивается CR-LF>.<CR-LF> 440 постинг не разрешен 441 сбой постинга (для справки, один из следующих кодов будет отправлен при инициализации соединения; клиентская программа должна определить разрешен-ли постинг вообще из этого:) 200 сервер готов - постинг разрешен 201 сервер готов - постинг запрещен 3.11 Команда QUIT 3.11.1 QUIT QUIT На команду QUIT сервер отрабатывает уведомление и затем закрывает соединение с клиентом. Это предпочтительный метод для клиента, чтобы показать, что он закончил все свои действия с NNTP сервером. Если клиент просто отключается (или происходит разрыв связи по таймауту, или происходит другой сбой), серрвер может постепенно остановить свои попытки обслуживать клиента. 11.2 Ответы 205 закрываю соединение - до свидания 12 Команда SLAVE 12.1 SLAVE SLAVE Команда показывает серверу, что его клиентское соединение является slave-сервером, а не просто пользователем. Эта команда предназначена для разделения соединений slave-серверов от простых пользователей. Она может использоваться для указания, что поэтому приоритет должен быть отдан именно этому клиенту, так как он, предположительно, обслуживает более одного пользователя. Она может также использоваться для решения какое соединение закрывать, когда возможности загрузки сервера заканчиваются, возможно отдавая приритет работе слэйв-сервера. Фактическое использование этой команды возложено на разработчиские реализации и может варьироваться от одного хоста к другому. В NNTP серверах, которые не дают приоритета slave-серверам, эта команда не должна быть опознана и подтверждена. 3.12.2 Ответы 202 статус slav'а учтен 4. Пример диалога Вот примеры диалога, который можно ожидать при гипотетической сессии с сервером новостей. Запись C: означает команду, данную серверу новостей клиентской программой; S: означает ответ, полученный клиентом от сервера. 4.1 Пример 1 - примерный доступ с командой NEXT S: (слушает TCP порт 119) C: (запрашивает NCP соединение по порту 119) S: 200 wombatvax сервер новостей готов - постинг разрешен (клиент запрашивает список групп новостей) C: LIST S: 215 список групп следует S: net.wombats 00543 00501 y S: net.unix-wizards 10125 10011 y S:(дополнительная информация здесь) S: net.idiots 00100 00001 n S: . (клиент выбирает группу) C: GROUP net.unix-wizards S: 211 104 10011 10125 net.unix-wizards group selected (в файле 104 статьи, с 1011 по 10125) (клиент выбирает статью для прочтения) C: STAT 10110 S: 223 10110 <23445@sdcsvax.ARPA> статья выбрана - просто статистика (выбрана статья 10110, ее идентификатор <23445@sdcsvax.ARPA>) (клиент проверяет заголовок) C: HEAD S: 221 10110 <23445@sdcsvax.ARPA> статья найдена - тело следует S: (текст статьи здесь) S: . (клиент выбирает следующую статью в группе) C: NEXT S: 223 10113 <21495@nudebch.uucp> статья найдена - просто статистика (статья 10113 была следующей в греппе) (клиент заканчивает сессию) C: QUIT S: 205 goodbye. 4.2 Пример 2 - полный доступ к статье с командой ARTICLE S: (слушает TCP порт 119) C: (запрашивает соединение по TCP порту 119) S: 201 UCB-VAX netnews сервер готов -- постинг не разрешен C: GROUP msgs S: 211 103 402 504 msgs ваша новая группа msgs (в группе 103 статьи, с 402 по 504) C: ARTICLE 401 S: 423 нет такой статьи в группе C: ARTICLE 402 S: 220 402 <4105@ucbvax.ARPA> статья найдена, текст следует S: (заголовок и тело статьи следуют) S: . C: HEAD 403 S: 221 403 <3108@mcvax.UUCP> Статья найдена, заголовок следует S: (заголовок статьи следует) S: . C: QUIT S: 205 UCB-VAX сервер новостей закрывает соединение. Пока. 4.3 Пример 3 - команда NEWGROUPS S: (слушает TCP порт 119) C: (запрашивает соединение по TCP порту 119) S: 200 Imaginary Institute сервер новостей готов - постинг разрешен (клиент запрашивает новые группы с 3 Апреля 1985) C: NEWGROUPS 850403 020000 S: 231 Новые группы с 03/04/85 02:00:00 следуют S: net.music.gdead S: net.games.sources S: . C: GROUP net.music.gdead S: 211 0 1 1 net.music.gdead группа выбрана (в этой группе нет статей, и номера первой и последней статьи должны игнорироваться) C: QUIT S: 205 Imaginary Institute сервер новостей прекращает обслуживание. Пока! 4.4 Пример 4 - посылка статьи S: (слушает TCP порт 119) C: (запрашивает соединение по TCP порту 119) S: 200 BANZAIVAX сервер новостей готов, постинг разрешен C: POST S: 340 Продолжайте постинг; Точка в пустой строке означает конец передачи. C: (передает статью в формате по RFC850) C: . S: 240 Статья отправлена успешно C: QUIT S: 205 BANZAIVAX закрывает соединение. Пока. 4.5 Прример 5 - раз'единение по запросу оператора S: (слушает TCP порт 119) C: (запрашивает соединение по TCP порту 119) S: 201 genericvax сервер новостей готов, постинг не разрешен (предполагаем нормальный диалог в течение некоторого времени, выбрана группа) C: NEXT S: 223 1013 <5734@mcvax.UUCP> статья найдена; текст отдельно. C: HEAD S: 221 1013 <5734@mcvax.UUCP> статья найдена; текст следует. S: (посылает заголовок статьи, но на полдороге прерывается по запросу оператора. Произойдет нижеслудеющие без вмешательства клиента.) S: (заканчивает текущую строку парой CR-LF) S: . S: 400 Соединение прервано оператором. Пока. S: (закрывает соединение) 4.6 Пример 6 - Использование сервера новостей для распространения новостей между системами. S: (слушает TCP порт 119) C: (запрашивает соединение по TCP порту 119) S: 201 Foobar NNTP сервер готов (постинг не разрешен) (клиент запрашивает новые группы с 2-х часов ночи 15-го Мая 1985 года) C: NEWGROUPS 850515 020000 S: 235 новые группы с 850515 следуют S: net.fluff S: net.lint S: . (клиент запрашивает новые статьи с 2-х часов ночи 15-го Мая 1985 года) C: NEWNEWS * 850515 020000 S: 230 Новые статьи с 850515 020000 следуют S: <1772@foo.UUCP> S: <87623@baz.UUCP> S: <17872@GOLD.CSNET> S: . (клиент запрашивает статью <1772@foo.UUCP>) C: ARTICLE <1772@foo.UUCP> S: 220 <1772@foo.UUCP> статья следует S: (передает статью) S: . (клиент запрашивает статью <17872@GOLD.CSNET> C: ARTICLE <17872@GOLD.CSNET> S: 220 <17872@GOLD.CSNET> статья следует S: (передает статью) S: . (клиент предлагает статью, что он только что получил) C: IHAVE <4105@ucbvax.ARPA> S: 435 же такую видел, где ты был ? (клиент предлагает другую статью) C: IHAVE <4106@ucbvax.ARPA> S: 335 Давай-ка мне эту статью! <CRLF.CRLF> в конце. C: (передает статью) C: . S: 235 статья передана успешно. Спасибо. (или) S: 436 Сбой передачи. (client is all through with the session) [?] C: QUIT S: 205 Foobar NNTP сервер прощается 4.7 Краткий обзор команд и ответов Нижеследующее - это команды и ответы, понимаемые и выводимые NNTP сервером. 4.7.1 Команды ARTICLE BODY GROUP HEAD HELP IHAVE LAST LIST NEWGROUPS NEWNEWS NEXT POST QUIT SLAVE STAT 4.7.2 Ответы 100 текст помощи следует 199 вывод информации отладчика 200 сервер готов - постинг разрешен 201 сервер готов - постинг запрещен 202 статус slave'а учтен 205 закрываю соединение - Пока. 211 n f l s группа выбрана 215 список групп следует 220 n <a> статья найдена - заголовок и тело следуют 221 n <a> статья найдена - заголовок следует 222 n <a> статья найдена - тело следует 223 n <a> статья найдена - запросите текст отдельно 230 список новых статей с сортировкое по идентификатору следует 231 список новых групп следует 235 статья передана успешно 240 постинг статьи ok 335 передавай статью для распростанения - окончание по <CR-LF>.<CR-LF> 340 передавай статью для постинга - окончание по <CR-LF>.<CR-LF> 400 сервис прерывается 411 нет такой группы 412 группа не выбрана 420 статья не выбрана 421 в группе нет _следующей_ статьи 422 в группе нет _пред'идущей_ статьи 423 нет статьи с таким номером 430 статья не найдена 435 статья не желательна - не передавай ее 436 сбой передачи - поробуй позже 437 статья отброшена - не пробуй заново 440 постинг не разрешен 441 сбой постинга 500 команда не опознается 501 ошибка в синтаксисе команды 502 доступ ограничен или нет доступа 503 сбой программы - команда не выполняется 4.8 Несколько слов о системе новостей USENET В мире UNIX, который традиционно был соединен телефонными линиями 1200 бод, система новостей USENET эволюционировала до поддержки центрального хранилища, индексирования, поиска и распространения новостей. За исключением лежащего в основе транспортного механизма (UUCP), новости USENET являются эффективным способом предоставления новостей и официальных сообщений подписчикам на UNIX и других хостах по всему миру. Система новостей USENET обсуждается в деталях в RFC850. Она работает на большинстве версий UNIX и на многих других операционных системах и обычно распространяется бесплатно. USENET использует буферную область на хосте UNIX для хранения статей, одна на файл. Каждая статья состоит из набора строк заголовка, который содержит идентификатор отправителя и организационное членство, временные штампы, пути ответа по электронной почте, тему, группу (категория темы), и т.п. Полная репродукция статьи приведена ниже. Обращайтесь к RFC850 за деталями. Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site sdcsvax.UUCP Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek !honman From: honman@unitek.uucp (Man Wong) Newsgroups: net.unix-wizards Subject: foreground -> background ? Message-ID: <167@unitek.uucp> Date: 25 Sep 85 23:51:52 GMT Date-Received: 29 Sep 85 09:54:48 GMT Reply-To: honman@unitek.UUCP (Hon-Man Wong) Reply-To: honman@unitek.UUCP (Hon-Man Wong) Distribution: net.all Organization: Unitek Technologies Corporation Lines: 12 References [1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC-822, Department of Electrical Engineering, University of Delaware, August, 1982. [2] Horton, M., "Standard for Interchange of USENET Messages", RFC-850, USENET Project, June, 1983. [3] Postel, J., "Transmission Control Protocol- DARPA Internet Program Protocol Specification", RFC-793, USC/Information Sciences Institute, September, 1981. [4] Postel, J., "Simple Mail Transfer Protocol", RFC-821, USC/Information Sciences Institute, August, 1982. Авторы выражают благодарности тем многим людям, которые способствовали написанию этой спецификации, и особенно Erik Fair и Chuq von Rospach. UNIX is a trademark of Bell Laboratories. оригинал документа - RFC-977 | ||
Andy © 2002-2004, 2009-2021