|
Bog BOS: Формат статей Netnews (USENET) и управляющие сообщения |
|
Последние изменения: |
Последнее изменение файла: 2007.02.08
Скопировано с www.bog.pp.ru: 2024.04.20
Общие сведения о Netnews (USENET): назначение, архитектура, протоколы и используемые программы.
Необходимо учитывать, что в Usenet одновременно действуют программы, рассчитанные на различные, не полностью совместимые версии стандарта. С формальной точки зрения действующим стандартом является RFC 1036 (1987 год), но уважения к такому "древнему" документу разработчики программ не испытывают и развитие Netnews идет в значительной мере стихийно (примерно, как развитие HTML в период борьбы между Microsoft и Netscape). "Неформальным" действующим стандартом является текст, написанный H. Spencer (News Article Format and Transmission, June 1994), который обычно называют son-of-RFC1036. К сожалению, данный текст не был внесен даже как проект (draft) в документы IETF и, с формальной точки зрения, не существует. Проект нового стандарта (draft-ietf-usefor-article) пишется уже 5-й год.
Хотя все стандарты Netnews (RFC 1036, son-of-RFC1036, draft-ietf-usefor-article) делают реверансы в сторону почтовых стандартов, заявляя, что формат почтовых сообщений (RFC 822, RFC 2822) и формат статей Netnews "почти" одинаковы, тем не менее, список различий весьма велик. Причем, убирая одни различия, очередная версия стандарта вносит новые. Различия проявляются даже в терминах. В стандартах Netnews сообщения называются статьями, а поля заголовков - заголовками. В основном, синтаксис статей определен более жестко, чем синтаксис почтовых сообщений. Ограничения в основном касаются лексики: не везде можно вставлять пробельные символы (нельзя между именем поля и двоеточием, но обязательно должен быть пробел после двоеточия); комментарии в скобках могут быть только в адресе (в конце); имя поля заголовка может содержать только буквы, цифры и знак "-"; нельзя использовать два минуса подряд в имени поля заголовка; нельзя использовать символ NUL и отдельные символы CR, LF. Часть ограничений была добавлена стандарт почтового сообщения при переходе от RFC 822 к RFC 2822, часть ограничений снята при переходе от RFC 1036 к draft-ietf-usefor-article (комментарии в скобках разрешаются в большем числе мест, но опять не везде).
Та же ситуация с MIME: фактически определяется своя версия MIME, которая является подмножеством почтового стандарта MIME (RFC 2045 - RFC 2049). На практике, MIME используется в Usenet не очень широко. При передаче двоичных файлов предпочтение до сих пор отдается uuencode, а тексты в KOI8-R передаются безо всяких опознавательных знаков.
draft-ietf-usefor-article предлагает использовать UTF-8 в теле статьи и некоторых заголовках (Subject, Newsgroups и т.д.), в то время как в почтовых сообщениях в заголовке и теле могут использоваться только символы ASCII (под ASCII или US-ASCII понимается ANSI X3.4, т.е. 7-битный кодовый набор), а прочие символы кодируются с помощью MIME.
Статьи Netnews имеют дополнительные заголовки по сравнению с почтовыми сообщениями и немного другую семантику одноименных с почтой заголовков.
Все программы должны быть прозрачны для 8-го бита (8-bit clean), т.е. принимать и передавать данные без изменения и "обрезания" 8-го бита. На практике, такие "варварские" программы встречаются до сих пор.
В стандартах RFC 1036 и son-of-RFC1036 в заголовках могут быть только символы ASCII, в теле статьи может использоваться 8-битная кодировка, но только в пределах подсети. draft-ietf-usefor-article предлагает использовать UTF-8 в теле статьи и некоторых заголовках.
Сообщение делится на строки и состоит из секции заголовков и тела сообщения (возможно пустого). Тело сообщения отделяется от секции заголовков пустой строкой (CRLF), которая должна присутствовать даже для пустого тела (чтобы отличить его от ошибочного сообщения с порезанным заголовком). Следует заметить, что хотя формат тела не определен, но передавать двоичные данные все же не следует, так как предполагается, что оно делится на строки, а символы конца строки могут модифицироваться при передаче в подсеть или при хранении (что будет с символом NUL и подумать страшно). Существуют также правила "хорошего тона": при цитировании предыдущего письма, цитируемый текст предваряется знаком ">" (без пробела!); перед подписью вставляется строка "-- " (обратите внимание на пробел перед концм строки!). Длина строки должна быть не более 998 символов, но желательно не порождать строк длиной более 78 символов (не считая CRLF).
Секция заголовков делится на заголовки, некоторые из которых являются обязательными. Опциональные заголовки описываются, но не являются обязательными. Можно добавлять свои заголовки (начинаются с X-). Порядок заголовков несущественен. Последствия присутствия нескольких полей с одинаковым именем непредсказуемы (явно запрещены для всех стандартизованных полей, кроме Comment, Keywords). Заголовок занимает одну логическую строку и состоит из имени заголовка (символы от 0x21 до 0x7e, кроме двоеточия), двоеточия и тела заголовка. Тело заголовка может быть разбито на несколько строк путем вставки CRLF перед пробельным символом (пробел или табуляция).
Сервер (релей и обслуживающий сервер) при распространении статьи не должен вносить в нее никаких изменений, кроме установки поля Xref и добавления себя в поле Path.
При отправке статьи от клиента серверу обязательными являются только поля From, Newsgroups и Subject. Остальные сервер может добавить сам.
From. Синтаксис адреса отправителя (и сопутствующего поля Sender) определяется форматом почтовых сообщений. Должен быть проверен на достоверность, хотя кто этому сейчас поверит?
Date. Синтаксис даты посылки статьи (ранее использовалось поле Posted) определяется форматом почтовых сообщений. Рекомендуется использовать GMT (UTC), но показывать в локальном времени.
Newsgroups. Статья может быть послана одновременно в несколько групп (crossposting), это отличается от посылки нескольких экземпляров статьи последовательно в несколько групп. Если в списке групп встречается модерируемая (-ые), то статья посылается для проверки модератору первой модерируемой группы. Имена групп новостей разделяются запятыми. Имена несуществующих групп игнорируются, но не удаляются (группа не создается простой посылкой статьи :). Имена групп строятся по иерархическому принципу аналогично именам файлов. Разделителем простых имен является точка. Простое имя начинается со строчной латинской буквы или цифры, остальные символы (до 13) - строчные латинские буквы, цифры, "-", "+", "_". В простом имени должна быть хотя бы одна буква. Ограничения на простое имя вызваны реализацией хранения статей в старых версиях INN и в настоящее время потеряли смысл. Во всяком случае, полно простых имен длиной более 14 символов, не содержащих ни одной буквы. Простые имена "all" и "ctl" зарезервированы по историческим причинам (также не соблюдается). Имеется различие в трактовке возможности использования прописных латинских букв в именах групп и их эквивалентности строчным у разработчиков различных программ. Предполагалось использовать MIME-кодирование для неанглийских имен групп, но на практике такое не встречалось. Имена групп, состоящие из одного простого имени, выделяются для локального или административного использования. Часто используются имена "control", "junk", "poster". Имена групп, начинающиеся с "to.", используются для организации очереди распространения статей соседям. Данное поле не может иметь строк продолжения (синтаксис не содержит пробелов).
Subject. Синтаксис темы статьи (ранее использовалось поле Title) определяется форматом почтовых сообщений. Если статья является ответом, то рекомендуется начинать поле со строки "Re: ", если такой строки еще нет. При наличии строки "Re: " требуется поле References. Не может начинаться с "cmsg ". Не может быть пустым. Шлюз из FIDO записывает тему в KOI8-r безо всякого преобразования, хотя допускается только ASCII.
Message-ID. Синтаксис уникального идентификатора определяется форматом почтовых сообщений. Уникальность обязательна - это свойство используется при распространении статей. Локальная часть чувствительна к регистру, доменная - нет. Нельзя использовать комментарии, пробельные символы и специальные символы даже в кавычках и за обратной косой чертой.
Path. Описывает путь (цепочку промежуточных хостов), по которому сообщение попало на данный хост. Каждая пересылающая система должна добавить свое имя (имя в смысле USENET, известное соседям, а не имя DNS!) в левую часть пути и отделить его восклицательным знаком (допускается любой знак пунктуации, кроме точки и тире, но лучше этого не делать). Имена хостов должны быть уникальны, проще всего добиться этого, используя имена DNS, но на практике никто за этим не следит. Самым правым должно быть локальная часть адреса отправителя (например, not-for-mail :), но некоторые вписывают полный почтовый адрес. Данное поле не может быть использовано для ответа или рассматриваться как почтовый адрес. Оно используется только для того, чтобы избежать зацикливания при распространении статьи. Данное поле не может иметь строк продолжения (синтаксис не содержит пробелов).
Reply-To. Синтаксис и семантика адреса для ответа определяется форматом почтовых сообщений.
Sender. Синтаксис и семантика адреса агента отправителя определяется форматом почтовых сообщений. Должен быть проверен на достоверность. Сомнительна, как и достоверность поля From.
Followup-To. Определяет список групп новостей, в которые должен направляться ответ. При отсутствии этого поля ответ направляется в те же группы, что и исходная статья (поле Newsgroups). Если заголовок содержит поле Keywords, то ответ должен отправляться почтой (?). Выделенное слово "poster" вместо имени группы означает, что ответ должен отправляться почтой. Очень редко используется.
Expires. Предполагаемая дата окончания существования статьи в формате поля Date. При отсутствии используется срок хранения по умолчанию, установленный на сервере. Администратор сервера может ограничить срок хранения даже тех статей, у которых установлено поле Expires. Очень редко используется.
References. Список через пробел уникальных идентификаторов статей (включая угловые скобки), на которые данная статья является ответом. Используется для группировки статей по темам (thread). Семантика отличается от поля с таким же названием почтового сообщения.
Control. Статья с таким полем управляет поведением серверов, рассылающих новости и не предназначена для чтения пользователями. Для совместимости, управляющими сообщениями считаются (считались?) сообщения отправленные в группу all.all.ctl или сообщения, у которых поле Subject начинается со строки cmsg.
Distribution. Список через запятую географических областей, позволяющий ограничить распространение статьи. Например, world, fido7 или ny (New York). Пространство имен никем не контролируется, так что возможны накладки и пользоваться этим средством опасно.
Organization. Описывает организацию, к которой принадлежит агент, пославший статью, или использованная для рассылки система.
Keywords. Набор ключевых фраз через запятую, по которым читатель может отбирать статьи. Очень редко используется.
Summary. Используется для выбора статей для чтения, аналогично полю Subject или группировки статей по темам (threads). Очень редко используется.
Approved. Добавляется модератором и содержит его почтовый адрес, если группа модерируется. Может содержать несколько адресов через запятую. Статьи, направленные в модерируемую группу и не содержащие правильного адреса в данном поле, отвергаются. Звучит наивно.
Lines. Число строк в теле сообщения. Доверять этому не стоит.
Xref. Содержит имя хоста, пробел, и список (через пробел) имен групп и номеров статей в группе на данном сервере, разделенных двоеточием. Имеет смысл только для данного сервера, так что при передаче статьи на другой сервер поле удаляется. RFC 1036 предлагает зачем-то опускать домен, но на практике это требование не выполняется.
Supersedes. Задает список идентификаторов сообщений через пробел, которые отменяются данной статьей. Запрещается одновременное использование с полями Control и Also-Control. Никакой защиты от неправомерных замещений чужих сообщений нет. Поле с таким же именем определяется для шлюза X.400. Введено в son-of-RFC1036.
Also-Control. Определяет данную статью одновременно как информационную, так и управляющую. Запрещается одновременное использование с полями Control и Supersedes. Введено в son-of-RFC1036.
See-Also. Содержит список идентификаторов статей через пробел, которые имеют отношение к данной статье, но не являются прямыми предшественниками в нити разговора (thread), как упоминаемые в References. Например, может содержать ссылки на остальные части сообщения, если единый документ был разбит на части при отправке. Введено в son-of-RFC1036.
Article-Names. Содержит список пар (через запятую) имя-группы:название-статьи и выделяет некоторые статьи. Преполагаются такие имена статей как faq, intro и т.п.. Популярностью не пользуется. Введено в son-of-RFC1036.
Article-Updates. Задает список идентификаторов сообщений через пробел, которые изменяются данной статьей. В отличие от поля Supersedes старая статья не удаляется. Введено в son-of-RFC1036.
Управляющие сообщения (см. поля Control и Also-Control) распространяются тем же способом, что и обычные статьи, но предназначены не для чтения пользователями, а для управления серверами USENET. Поле Control содержит несколько слов, разделенных пробельными символами. Первое слово является именем команды, остальные - ее параметрами. Потенциальными параметрами могут быть также остаток заголовка и тело сообщения. Управляющие сообщения могут обрабатываться автоматически (безумная мысль) или складываться в очередь для ручной обработки.
cancel. Параметром является список идентификаторов сообщений через пробел, которые необходимо удалить из базы данных сервера. Посылать такое сообщение разрешено либо автору удаляемого сообщения, либо администратору местного сервера (проверяется по полю Sender или From, что опять-таки наивно и приводит к многочисленным войнам по удалению "непонравившихся" сообщений). По правилам, сообщения об отмене должны посылаться в ту же группу и с тем же distributions, что и исходное сообщение. На практике, они посылаются в группу cancel. Если сообщение об удалении пришло раньше исходного, то предлагается занести идентификатор исходного сообщения в базу данных сообщений, так что при его реальном прибытии оно будет отвергнуто как дубль.
ihave и sendme. Протокол запроса на передачу статьи и разрешения на передачу. В настоящее время практически не используются (осталось ли еще у кого-нибудь UUCP?). Аналогичные. но более эффективные средства есть непосредственно в протоколе NNTP.
newgroup. Создание новой группы, имя которой задается первым параметром. При наличии второго параметра в виде ключевого слова moderated группа является модерируемой (поле Approved при этом содержит почтовый адрес модератора). Сообщение должно содержать поле Approved. Если группа с таким именем уже существует, то нужно заменить ее статус модерируемости или описание. Тело сообшения описывает новую группу. К сожалению, в мире полно сумасшедших, рисующих ASCII-картинки из имен групп.
rmgroup. Удаление указанной группы. Требуется наличие поля Approved с правильным адресом модератора. Разрешать автоматическое исполнение данной команды нельзя ни в коем случае.
sendsys. Запрос на посылку списка соседей сервера и списка групп новостей, которые сервер посылает им. Данная информация считается открытой и собирается для составления карты USENET. Может содержать в качестве параметра имя соседа, которым надо ограничиться. Адрес получателя берется из поля Reply-To или From. Локальная часть адреса должна быть строкой newsmap. Сообщение должно содержать поле Approved. Отправка сообщения должна быть задержана на 24 часа (защита от подстав).
version. Запрос на посылку названия и версии сервера. Адрес получателя берется из поля Reply-To или From. Локальная часть адреса должна быть строкой newsmap. Сообщение должно содержать поле Approved. Отправка сообщения должна быть задержана на 24 часа (защита от подстав).
whogets. Запрос на посылку списка соседей, получающих от сервера указанную в качестве параметра группу. Адрес получателя берется из поля Reply-To или From. Локальная часть адреса должна быть строкой newsmap. Сообщение должно содержать поле Approved. Отправка сообщения должна быть задержана на 24 часа (защита от подстав).
checkgroups. Тело сообщения на каждой строке содержит имя и описание группы новостей. Имена групп, не совпавших с локальным списком посылаются по адресу usenet (?).
Поля заголовка, которые могут быть добавлены шлюзом FIDO -> USENET:
Шлюз fido.aha.ru добавляет заголовки MIME, что позволяет использовать русские тексты без преобразований.
|
Bog BOS: Формат статей Netnews (USENET) и управляющие сообщения |
|
Последние изменения: |