= Сообщение: 1269 из 2735 =================================== RU.FTN.DEVELOP = От : FGHI Robot 2:50/88 02 Sep 17 01:27:44 Кому : All 02 Sep 17 01:27:44 Тема : Черновик стандарта FGHI URL (русская версия) FGHI : area://RU.FTN.DEVELOP?msgid=2:50/88+59a9dee0 = Кодировка сообщения определена как: IBM866 ================================= ============================================================================== ********************************************************************** FGHI FIDONET GLOBAL HYPERTEXT INTERFACE ********************************************************************** Статус: черновик Номер редакции: 0.5pre Заглавие: FGHI URL, средства Единой Формы Адресации Ресурсов для фидонетовских объектов и служб Автор: Mithgol the Webmaster (Sergey Sokoloff, 2:50/88) Спасибо за помощь: Shannar (Boris Kassal, 2:463/587) Trooper (Alexey Bezugly, 2:5030/1520.9) NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1) Inity (Tanya Matveeva, 2:5030/1400) Дата редакции: 8 Apr 2010 -+-------------------------------------------------------------------- Содержание: 1. Статус этого документа 2. Введение 3. Ключевые слова для выражения уровней требуемости 4. Список изменений этого документа 5. Общий синтаксис URL-адресов Фидонета 5.1. Главные части URLов 5.1.1. Примечание о соответствии 5.1.2. Руководство по употреблению отделителей 5.2. Кодирование символов в URLах 5.2.1. Кодирование изначальных символов 5.2.2. Кодирование октетов 5.2.2.1. Нет соответствующего 7-битного видимого символа 5.2.2.2. Небезопасные символы 5.2.2.3. Зарезервированные символы 5.2.2.3.1 Использование доменных суффиксов в ареатагах 5.2.2.4. Плюс ("+") и кодирование пробелов 5.2.2.4.1. Примечание об особенности 5.2.2.4.2. Примечание об интернетовском обычае 5.2.2.5. URLы, занимающие несколько строк текста в Фидо 5.3. Разбор части URLа, особенной для каждой из схем 5.3.1. Обработка неуместных зарезервированных символов 6. Схемы URLов Фидонета, означающих действия 6.1. Схема "netmail:" 6.1.1. Необязательный параметр "to" 6.1.2. Необязательный параметр "subject" 6.1.4. Необязательный параметр "from" 6.1.5. Необязательный параметр "body" 6.2. Схема "areafix:" 6.2.1. Необязательный параметр "uplink" 6.2.2. Необязательный параметр "leave" 6.2.3. Необязательный параметр "fecho" 6.2.4. Будущие необязательные параметры 6.2.5. Относительные URLы "areafix:" 6.3. Схема "echomail:" 6.3.1. Необязательный параметр "to" 6.3.2. Необязательный параметр "subject" 6.3.4. Необязательный параметр "from" 6.3.5. Необязательный параметр "body" 7. Схемы URLов Фидонета, означающих объекты 7.1. Часть адреса <путь-объекта>. Возможные формы пути 7.1.1. Предшествующая косая черта и завершающая косая черта 7.1.2. Обработка неизвестных контейнеров 7.2. Схема "area://" 7.2.1. Фильтры сообщений 7.2.1.1. Фильтры типа "msgid" 7.2.1.2. Фильтры типа "time" 7.2.1.2.1. Одиночный момент 7.2.1.2.1.1. Пустые значения 7.2.1.2.2. Верхний предел 7.2.1.2.2.1. Пустые наиболее левые значения 7.2.1.2.2.2. Пустые наиболее правые значения 7.2.1.2.3. Нижний предел 7.2.1.2.3.1. Пустые наиболее левые значения 7.2.1.2.3.2. Пустые наиболее правые значения 7.2.1.2.4. Интервал времени 7.2.1.2.4.1. Пустые наиболее правые значения 7.2.1.2.4.2. Пустые наиболее левые значения 7.2.1.2.5. Комплексный фильтр 7.2.1.2.6. Типовое множество подытога фильтров "time" 7.2.1.2.7. Порядковый номер дня в году 7.2.1.2.8. Использование текущей даты и времени 7.2.1.2.9. Кладж TrueTime 7.2.1.2.10. Необязательный параметр "usetz" 7.2.1.2.11. Будущие варианты фильтров "time" 7.2.1.3. Фильтры типа "from" 7.2.1.3.1. Фильтры типа "twit" 7.2.1.4. Фильтры типа "find" 7.2.1.4.1. Сходные фильтры: "subj", "findsb", "to", "sender" 7.2.1.5. Географическая привязка эхопочты 7.2.1.5.1. Кладж GEO 7.2.1.5.2. Кладж GEOBOX 7.2.1.5.3. Кладж GEOKML 7.2.1.5.4. Координаты в ноудлистах и пойнтлистах 7.2.1.5.5. Кладж ORIGEO 7.2.1.5.6. Фильтры типа "geomark" 7.2.1.5.7. Фильтры типа "geofrom" 7.2.1.6. Эхопочта, снабжённая ярлыками 7.2.1.6.1. Кладж TAG 7.2.1.6.2. Фильтры типа "tag" 7.2.1.7. Фильтры типа "ttop" 7.2.1.8. Будущие фильтры сообщений 7.2.2. Закодированные объекты внутри эхопочтовых сообщений 7.2.2.1. Имена кодированных объектов 7.2.2.2. Как определяется означенный объект 7.2.2.2.1. Возможные приложения 7.2.3. Вид представления сообщений 7.2.3.1. Необязательный параметр "view" 7.2.3.2. Вид единственного сообщения 7.2.3.3. Список сообщений 7.2.3.4. Дерево ответов 7.2.3.5. Ветвь ответов 7.2.3.6. Список деревьев 7.2.3.7. Лента сообщений 7.2.3.8. Лента вершин деревьев 7.2.3.9. Список вершин деревьев 7.2.3.10. Развёрнутое дерево 7.2.3.11. Развёрнутая ветвь 7.2.3.12. Плоское дерево 7.2.3.13. Плоская ветвь 7.2.3.14. Календарь 7.2.3.15. Карта сообщений 7.2.3.16. Карта отправителей 7.2.3.17. Глобус сообщений 7.2.3.18. Глобус отправителей 7.2.3.19. Список кодированных объектов 7.2.3.20. Эхолист 7.2.4. Управление видимостью кладжей и скрытых строк 7.2.4.1. Необязательный параметр "kl" 7.2.5. Необязательный параметр "full" 7.2.6. Порядок сортировки сообщений 7.2.6.1. Необязательный параметр "sort" 7.2.6.2. Без сортировки (в порядке базы сообщений) 7.2.6.3. Хронологическая сортировка 7.2.6.4. Сортировка по релевантности 7.2.6.5. Сортировка по теме 7.2.6.6. Сортировка по объёму 7.2.6.7. Сортировка по имени адресата 7.2.6.8. Сортировка по имени отправителя 7.2.6.9. Сортировка по адресу отправителя 7.2.6.10. Сортировка по местонахождению отправителя 7.2.6.11. Сортировка по ареатагу 7.2.7. Необязательный параметр "leaf" 7.3. Схема "faqserv://" 7.3.1. Необязательный параметр "time" 7.3.2. Необязательный параметр "bot" 7.3.3. Необязательный параметр "loc" 7.3.4. Будущие необязательные параметры 7.4. Схема "fecho://" 7.4.1. Необязательный параметр "time" 7.4.2. Будущие необязательные параметры 7.5. Схема "freq://" 7.5.1. Необязательный параметр "time" 7.5.2. Необязательный параметр "size" 7.5.3. Необязательный параметр "ed2k" 7.5.4. Необязательный параметр "aich" 7.5.5. Необязательный параметр "fecho" 7.5.6. Расширение на основе URL для файловых запросов WaZOO 7.5.7. FGHI URLы файловых откликов (.FUF-индекс) 7.5.8. Флаги ноудлиста, указывающие на возможности FGHI freq 7.5.9. Будущие необязательные параметры Приложение A. Регулярные выражения Приложение B. Известные реализации B.1. HellEd B.2. FGHI URL гейт B.3. NoSFeRaTU's GoldED+ Приложение C. Прозреваемые грядущие технологии C.1. XML-эхолисты C.2. FFF (фенечки фидосферы FGHI) C.2.1. Социальный файл (кладж SOCFILE) -+--------------------------------------------------------------------
Я русский человек, и все свои знания, весь свой труд, все свои достижения я имею право отдавать только моей родине. Я горд тем, что родился русским. И если не современники, то, может быть, потомки наши поймут, как счастлив я, что не за рубежом, а в России открыто новое средство связи.
1. Статус этого документа -+-----------------------
Этот документ является переводом на русский язык, соответствующим черновику Предлагаемого Фидонетовского Стандарта (FSP).
Оригинал этого документа описывает необязательный фидонетовский стандарт, который может использоваться как фидошным сообществом, так и в Паутине, и призывает к обсуждению и предложению доработок.
Реализация протоколов, определённых в этом документе, не является необходимою; но ожидается, что все реализации этих протоколов будут соответствовать данному стандарту.
Распространение этого документа не ограничивается, если в его текст при распространении не будут внесены изменения, не упомянутые явно.
"Редакция 0.5pre" является ночной сборкою черновика, выпускаемою, чтоб осведомить большинство разработчиков (на Ru.FTN.Develop подписанных) о самых последних изменениях этого документа. Она может содержать неоконченные и (или) неотшлифованные разделы. В окончательном итоге она станет серьёзным выпуском (0.5 или 1.0rc). Русский перевод "редакции 0.5pre" может не вполне соответствовать английскому тексту. Если вы найдёте какие-либо баги в 0.5pre, осведомите автора.
2. Введение -+---------
В этом документе определяется несколько фидонетовских схем для Единой Формы Адресации Ресурсов -- для записи URL-адресов, которыми обеспечивается единообразно оформленная информация о местонахождении и о способах доступа к ресурсам и службам через Фидонет.
Определение их спланировано с тем расчётом, чтобы соответствовать спецификациям RFC 1738; и оттого гиперссылки, заданные по указаниям данного документа, могут использоваться как в Фидонете (в эхопочте, в нетмейле), так и в традиционном HTML-гипертексте в рамках Паутины и интернетовского e-mail (где стандарты URLов в основном обратно совместимы с RFC 1738).
Давая каждому фидонетовскому ресурсу его собственный URL (адрес единой формы), сей стандарт делает не требующими усилий следующие две задачи:
1) Указание на ресурс теперь не требует усилий: просто укажите URL вместо того, чтобы утруждать себя объяснением того, как найти этот ресурс.
2) Найти ресурс теперь не требует усилий: просто следуйте URLу (например, жмякните по гиперссылке) вместо того, чтобы утруждать себя поиском вручную.
Обратите внимание: URL может быть скопирован из одной программы, а затем вставлен в другую, если обе они поддерживают стандарт. См. в Приложении B список реализаций предыдущих версий сего документа.
Помимо самостоятельного предназначения, этот документ также послужит первой и наиболее основной частью FGHI (произносится 'фигхай'; это сокращение слов 'Fidonet Global Hypertext Interface', означающих фидонетовский всеобщий гипертекстовый интерфейс), целью которого будет гипертекстовая автоматизация некоторых покуда ручных операций Фидонета, доставка и просмотр иллюстрированного гипермедиа по традиционным каналам эхопочтовых и нетмейловых текстовых соединений, а также, возможно, некоторые другие элементы гипертекстового Фидонета.
2.1. Список введённых особенностей Фидонета -+-----------------------------------------
Этот документ определяет семь новых схем URLов:
*) netmail: (в разделе 6.1) *) areafix: (в разделе 6.2) *) echomail: (в разделе 6.3) *) area:// (в разделе 7.2) *) faqserv:// (в разделе 7.3) *) fecho:// (в разделе 7.4) *) freq:// (в разделе 7.5)
Этот документ определяет шесть новых необязательных кладжей:
*) TrueTime (в разделе 7.2.1.2.9) *) GEO (в разделе 7.2.1.5.1) *) GEOBOX (в разделе 7.2.1.5.2) *) GEOKML (в разделе 7.2.1.5.3) *) ORIGEO (в разделе 7.2.1.5.5) *) TAG (в разделе 7.2.1.6.1)
Этот документ определяет восемь новых необязательных ноудлистовых флагов:
*) LONE, LONW, LATN, LATS (в разделе 7.2.1.5.4) *) FUF, FUFME, FUFP, FUFD (в разделе 7.5.8)
Этот документ определяет обладающее обратной совместимостью расширение на основе URL для файловых запросов WaZOO (в разделе 7.5.6). Вводится (в разделе 7.5.7) индексный файл откликов (файл .FUF), подобный известному прежде индексному файлу запросов (файлу .REQ).
3. Ключевые слова для выражения уровней требуемости -+-------------------------------------------------
Ключевые слова "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" и "OPTIONAL" в оригинале этого документа имеют смысл, соответствующий описаниям в стандарте FTA-1006 (основанном на RFC 2119).
В этом русском переводе используются следующие ключевые выражения:
4. Список изменений этого документа -+---------------------------------
Номера разделов в этом списке изменений могут соответствовать прежним версиям этого документа; настоящие номера иногда меняются без предупреждения по мере введения новых разделов.
В версии 0.5pre: [8 Apr 2010]
*) в необязательном параметре "loc" теперь указывается, посылать ли запрос к FAQ-серверу в строке заголовка нетмейла или в теле сообщения (раздел 7.3.3) *) необязательные параметры "subj" перестали быть частью стандарта: раздел 5.2.2.5 определяет URLы, занимающие несколько строк текста, так что теперь всегда будет безопасно использовать необязательные параметры "subject" *) необязательный параметр "unsubscribe" также сгинул, используйте "leave" (раздел 6.2.2) *) добавлен краткий список введённых особенностей Фидонета (раздел 2.1) *) необязательный параметр "fecho" (раздел 6.2.3) в URLах "areafix:" может использоваться для изменения подписки на файлэхопочту *) эхопочта теперь может снабжаться ярлыками и фильтроваться по ним (раздел 7.2.1.6) *) значения фильтров "find" могут теперь содержать простой текст, не только регулярные выражения (раздел 7.2.1.4) *) добавлены ещё фильтры ("subj", "findsb", "to", "sender"), чтобы вести поиск в различных элементах сообщения (раздел 7.2.1.4.1) *) добавлено несколько необязательных параметров в URLы "freq://" (разделы 7.5.2, 7.5.3, 7.5.4, 7.5.5), так что если файлы уже доступны в файловых эхах и (или) в сети ed2k/Kad, они могут быть запрошены из альтернативного источника (или, совсем наоборот, freq-сервер может стать проксёю альтернативных источников файла) *) один URL "fecho://" может содержать несколько ареатагов (раздел 7.4), означая файл, одновременно опубликованный (cross-posted) в нескольких файловых эхах *) добавлен необязательный параметр "time" в URLах "faqserv://" (раздел 7.3.1), и в URLах "fecho://" (раздел 7.4.1), и в URLах "freq://" (раздел 7.5.1), чтобы помочь в кешировании объектов *) добавлен кладж ORIGEO (раздел 7.2.1.5.5), содержащий координаты отправителя, если (и когда) они не присутствуют в ноудлисте или в пойнтлисте *) добавлен необязательный FGHI URL в качестве элемента файловых запросов WaZOO (раздел 7.5.6) *) добавлен необязательный параметр "view", чтобы содержать информацию о рекомендуемом режиме просмотра представленных сообщений (раздел 7.2.3) *) необязательный параметр "usetz" теперь также управляет тем, какие сообщения соответствуют каким датам в календарном виде (раздел 7.2.3.14) и используется ли UTC во время хронологической сортировки (раздел 7.2.6.3) *) добавлена пометка о соответствии RFC 4395 в разделе 5.1.2 *) добавлен необязательный параметр "full" для развёртывания свёрнутых сообщений (раздел 7.2.5) *) добавлено разъяснение в разделе 5.3: если значение по умолчанию для параметра не приведено в этом стандарте, то оно определяется либо пользовательскими настройками, либо тем, как устроен фидонетовский браузер *) добавлены три примера возможных приложений постоянных URLов содержимого, обновляемого по Фидонету (в разделе 7.2.2.2.1) *) добавлен новый необязательный параметр "sort" для управления порядком сообщений (раздел 7.2.6) *) расширен формат файлового запроса WaZOO (файла .REQ), указано, как он может содежать URLы FGHI (раздел 7.5.6) *) добавлен новый отклик freq-сервера (файл .FUF), он содержит URLы FGHI, которые могут накапливаться во время кеширования запрошенных файлов (раздел 7.5.7) *) географические координаты в ноудлистах и пойнтлистах теперь должны отделяться от соответствующего флага двоеточием, и точка должна использоваться для разделения целой и дробной частей десятичного числа (раздел 7.2.1.5.4) *) добавлены два флага ноудлиста, указывающие на возможности FGHI freq (раздел 7.5.8) *) добавлен новый фильтр "ttop" (раздел 7.2.1.7) для выборки только тех сообщений, которые начинают новые нити обсуждения (то есть не являются ответами ни на одно сообщение в той же области эхопочты) *) добавлен новый фильтр ("twit", раздел 7.2.1.3.1), чтоб поставлять списки твитов *) добавлена Inity в список благодарностей (мозговой штурм получился по-настоящему замечательным) *) FGHI теперь означает Fidonet Global Hypertext Interface *) добавлено Приложение B (список известных реализаций URLов FGHI)
В версии 0.4: [13 Oct 2007]
*) переименованы необязательные параметры, идентифицирующие сообщения; теперь они называются фильтрами сообщений (см. разделы 7.2.1, 7.2.2.2 и их подразделы) *) несколько фильтров одного и того же типа могут теперь использоваться одновременно *) флаг "/m" теперь всегда подразумевается в регулярных выражениях (приложение A), так что его можно пропускать при поиске кладжей (раздел 7.2.1.4) *) новый (более разумный) перевод: Uniform Resource Locators = Единая Форма Адресации Ресурсов *) теперь запросы по умолчанию не могут подразумеваться в адресах "faqserv://" (раздел 7.3) *) к ареатагам добавлен необязательный суффикс "@domain" для различения между разными FTNами (по просьбе Скотта Литтла) в адресах "area://" (раздел 7.2), в адресах "areafix:" (раздел 6.2), и в адресах "fecho://" (раздел 7.4); символ "@" теперь является зарезервированным внутри ареатагов (раздел 5.2.2.3.1) *) единый перевод: echomail = эхопочта (и нигде никаких эхомейлов) *) добавлен абзац для прояснения разницы между не поддающимися декодированию объектами и неизвестными контейнерами (в разделе 7.2.2.2) *) несколько аплинков и (или) списков аплинков могут быть указаны в URLах "areafix:" (раздел 6.2.1) *) один URL "areafix:" может содержать несколько ареатагов (раздел 6.2), так что теперь возможною стала подписка на несколько эх при помощи единственного жмяка мышою (по просьбе Дмитрия Гайворонского) *) один URL "echomail:" может содержать несколько ареатагов (раздел 6.3) для поддержки кросс-постинга сообщений (то есть сообщения рассылаются в несколько эх при помощи единственного жмяка мышою) *) один URL "area://" может содержать несколько ареатагов (раздел 7.2), означая набор сообщений из нескольких областей эхопочты *) многострочные URLы (по просьбе Алекса Кочарина) теперь возможны (раздел 5.2.2.5) *) фильтры типа "mid" больше не нужны, вместо них используйте "msgid" (соответствующий раздел удалён) *) новый фильтр сообщений "time" (раздел 7.2.1.2) и кладж TrueTime (подраздел 7.2.1.2.9) *) эхопочта может содержать географическую привязку (раздел 7.2.1.5) и фильтроваться географически
В версии 0.3: [10 Feb 2007]
*) начат этот список изменений *) добавлен подраздел 7.2.1.3 (Необязательный параметр "from") *) добавлен подраздел 7.2.1.4 (Необязательный параметр "find") *) отредактирован обрамляющий подраздел 7.2, чтоб отразить тот факт, что теперь можно идентифицировать несколько сообщений, не только одно сообщение *) добавлено спасибо за помощь NoSFeRaTU *) отредактирован подраздел 5.2.2.4.2, упомянут RFC 1630 *) отредактирован список примеров в разделе 5 *) добавлено приложение A (Регулярные выражения) *) добавлен подраздел 7.2.4 (Управление видимостью кладжей и скрытых строк) *) отредактирован подраздел 5.2.2.2, слово "Origin" теперь не является небезопасным *) отредактирован подраздел 7.5.1, чтоб отразить тот факт, что ответы на запросы могут задерживаться
5. Общий синтаксис URL-адресов Фидонета -+-------------------------------------
Так как существует много различных типов фидонетовских объектов и служб, то несколько схем URL созданы для описания местонахождения этих ресурсов.
Обобщённый синтаксис URLов обеспечивает каркас, на основе которого могут описываться новые схемы -- в том числе и с применением других протоколов, в данном документе не описанных.
URLы используются для определения местонахождения ресурсов, так как любой URL содержит абстрактный идентификатор такого местонахождения. Определив местонахождение ресурса, фидонетовская система может с ним произвести любую необходимую операцию из числа доступных системе (их мы можем перечислять с использованием таких терминов, как 'получить доступ', 'подписаться', 'отписаться', 'послать', 'запросить', 'показать атрибуты').
5.1. Главные части URLов -+----------------------
В общем, фидонетовские URLы записываются вот так:
<схема>:<особенная-часть>
Каждый URL содержит имя используемой им схемы (<схема>), а за ним двоеточие, а за ним набор символов (<особенная-часть>), понимание которого зависит от используемой схемы.
Имя схемы является последовательностью символов. В ней разрешается употреблять строчные латинские буквы "a"--"z", цифры, символ плюса ("+"), точку ("."), дефис ("-"). В силу соображений совместимости, разбирающим фидонетовский URL программам НАДОБНО обрабатывать заглавные латинские буквы в именах схем как эквивалентные строчным, им соответствующим (например, принимать имя схемы "AREA" в качестве "area").
Только первое двоеточие в URLе играет роль отделителя, отделяющего часть адреса <схема> от части <особенная-часть>. Особенная часть всякого URLа МОЖЕТ содержать и другие двоеточия.
За двоеточием-отделителем между <схема> и <особенная-часть> МОЖЕТ непосредственно идти необязательная двойная косая черта ("//"). Фидонетовские программы, разбирающие URL, ДОЛЖНЫ обрабатывать отделитель "://" в качестве эквивалентного обычному двоеточию перед <особенная-часть>.
5.1.1. Примечание о соответствии -+------------------------------
Этот подраздел приводится для сведения.
Фидонетовские схемы URLов, описываемые в этом документе, состоят только из строчных латинских букв "a"--"z". Однако как цифры, так и символы плюса ("+"), точки (".") и дефиса ("-") ДОЛЖНЫ также дозволяться в именах схем, чтобы обеспечить корректную обработку интернетовских схем, соответствующих спецификациям RFC 1738.
5.1.2. Руководство по употреблению отделителей -+--------------------------------------------
Обычаи нынешнего Интернета проводят некоторое различие между отделителями ":" и "://". Отделитель "://" часто применяется после имён схем, означающих объекты и ресурсы ("http://", "ftp://", "gopher://", "nntp://", "ed2k://", "file://" и т. д.). Отделитель ":" часто употребляется после имён схем, означающих действия (например, "mailto:", "skype:").
Аналогичная разница существует между фидонетовскими ресурсами (объектами) и действиями. Вот почему, хотя эти отделители ДОЛЖНЫ всегда обрабатываться как эквивалентные, всё же РЕКОМЕНДУЕТСЯ использовать ":" после схем, означающих действия ("netmail:", "echomail:", "areafix:"), а "://" СЛЕДУЕТ использовать после схем, означающих ресурсы ("area://", "freq://", "fecho://", "faqserv://").
Эта РЕКОМЕНДАЦИЯ также соответствует разделу 2.2 из RFC 4395, поскольку каждый из URLов фидонетовских ресурсов МОЖЕТ содержать иерархическую структуру каталогов и контейнеров (см. раздел 7.1 ниже), так что использование двойных косых черт показывает, что за ними следует верхний иерархический элемент.
5.2. Кодирование символов в URLах -+-------------------------------
URLы являются последовательностями символов, то есть букв, цифр, и (или) спецсимволов. URLы могут быть записаны разными способами; например, чернилами на бумаге, или последовательностью октетов кода, соответствующих символам в некоторой кодировке. Обработка URL не зависит от этого способа, а только от значения символов, в URL использованных.
Полезно различать два понятия: "символ" (элемент письменности, семантическая единица) и "октет" (восьмибитный байт).
В большинстве схем URLов последовательности символов, стоящие в разных частях URLа, отражают собою последовательности октетов, используемых в фидонетовских службах. Скажем, в схеме "netmail:" такими последовательностями октетов являются фидонетовский адрес, заголовок письма и имя адресата; части URLа служат представлением этих последовательностей. Последовательности же октетов, в свою очередь, являются кодированным представлением изначальных символов (символов заголовка, символов имени сисопа и т. д.); каждому из изначальных символов соответствует один октет или более.
Таким образом, всегда существует два соответствия: символам URLов соответствуют октеты, а октетам соответствуют изначальные символы:
запись URLа <-> последовательность октетов <-> изначальные символы
5.2.1. Кодирование изначальных символов -+-------------------------------------
Следующий абзац приводится для сведения.
Последовательность октетов, определяемая той или иною частью URLа, является представлением последовательности символов, изначально используемых в Фидонете. Процесс этот обладает весьма разнообразной природою. Будучи международной сетью, Фидонету всегда приходится иметь дело с сотнями национальных символов, с десятками имеющихся традиций кодирования и наборов символов. И есть уже целый ряд FSC (документов фидонетовских стандартов), предлагающих различные способы на основе кладжей указать, какой набор символов используется. Однако не было бы мудрым решение реализовать какие бы то ни было эквиваленты кладжей в качестве необходимого элемента каждого из фидонетовских URLов; а также было бы непросто поддерживать полный список всевозможных наборов символов внутри каждой из программ, обрабатывающих фидонетовские URLы. (Не забудьте, что одной из целей является возможность как появления, так и правильной обработки фидонетовских URLов внутри традиционного HTML-гипертекста в Паутине, интернетовском e-mail, мгновенных сообщениях, и т. п.) Вот почему приходится выбрать только одну кодировку, с достаточно обширным набором символов.
Дальнейшие абзацы этого подраздела приводятся для указания.
Последовательность октетов, используемая в фидонетовских URLах, ДОЛЖНА всегда содержать представление изначальных символов, достигнутое кодированием их в UTF-8.
Стандарт ISO/IEC 10646-1 определяет многооктетный набор символов под названием Universal Character Set (т. е. Универсальный Набор Символов, UCS), охватывающий большинство существующих в мире систем письменности. И UTF-8, один из так называемых форматов преобразования UCS (UCS transformation formats, UTF), сохраняет семибитное подмножество ASCII неизменным, обеспечивая тем самым некоторую совместимость с файловыми системами, обработчиками и другими элементами программного обеспечения, которые полагаются на значения семибитного ASCII, а по отношению к другим значениям проявляют терпимость.
UTF-8 описывается в RFC 2279. Его описание также можно найти в Unicode Technical Report #4 и в стандарте Unicode версии 2.0.
Последовательности символов в различных частях URLа используются для представления последовательностей октетов.
Существует возможность представить октет при помощи символа, соответствующего этому октету по коду в чистом (семибитном) наборе символов ASCII. Однако есть некоторые исключения (см. ниже).
Другой вариант: октеты МОГУТ также быть закодированы при помощи тройки символов, состоящей из символа "%", за которым идут две шестнадцатиричных цифры (из набора "0123456789ABCDEF"), которые образуют шестнадцатиричное значение октета. (Символы "abcdef" также МОЖНО использовать при шестнадцатиричном кодировании.)
Шестнадцатиричное кодирование любого октета МОЖЕТ использоваться даже в тех случаях, когда оно не является ТРЕБУЕМЫМ, не является РЕКОМЕНДУЕМЫМ. Тем не менее, РЕКОМЕНДУЕТСЯ избегать ненужного шестнадцатиричного кодирования, чтобы URLы получались покороче.
Использование шестнадцатиричного кодирования октетов становится НЕОБХОДИМЫМ или РЕКОМЕНДУЕМЫМ, если для них нет соответствующего семибитного видимого символа в ASCII, или если употребление соответствующего символа небезопасно, или если соответствующий символ был зарезервирован для другого истолкования в конкретной схеме URL. Эти требования и рекомендации излагаются ниже.
5.2.2.1. Нет соответствующего 7-битного видимого символа -+------------------------------------------------------
URLы записываются только при помощи графических (видимых, печатаемых) символов семибитной кодовой таблицы ASCII.
Октеты 80-FF (это дан шестнадцатиричный код их) не принадлежат к семибитному ASCII, а октеты 00-1F и 7F (шестн.) обозначают управляющие символы ASCII; эти октеты ДОЛЖНЫ кодироваться.
Символ пробела является небезопасным, так как значащие пробелы могут исчезнуть и незначащие пробелы могут быть добавлены при записи или наборе URLов, а также при обработке текста с URLами в текстовых процессорах. Октет 20 (шестн.) ДОЛЖЕН всегда быть закодирован.
Символы "<" и ">" небезопасны, поскольку они употребляются как разделители вокруг тэгов в HTML-гипертексте и в XML-данных. Октеты 3C и 3E (шестн.) ДОЛЖНЫ всегда быть закодированы.
Символ кавычки (""") используется как разделитель вокруг URLов в некоторых системах, в том числе в корректно записанном XHTML и XML. Октет 22 (шестн.) ДОЛЖЕН всегда быть закодирован.
Символ "#" небезопасен, поскольку он используется во Всемирной Паутине и в иных системах для отделения URLа от идентификатора фрагмента или якоря, который может следовать за URLом. Октет 23 (шестн.) ДОЛЖЕН всегда быть закодирован.
Символ "%" небезопасен, так как он используется в кодировании других символов. Октет 25 (шестн.) ДОЛЖЕН всегда быть закодирован.
Символьная последовательность тройного минуса (символ "-", повторённый трижды) имеет специальное значение в Фидонете и может случайно начать тиарлайн в некоторых случаях (скажем, после переноса на новую строку). Как минимум один из трёх соответствующих октетов (2D 2D 2D шестн.) ДОЛЖЕН быть закодирован, если они следуют друг за другом последовательно.
Другие символы были определены как небезопасные в RFC 1738, поскольку некоторые гейты и другие транспортные агенты были известны в качестве модифицирующих эти символы иногда. Вот эти символы: "{", "}", "|", "\", "^", "~", "[", "]" и "`". Соответствующие им октеты (7B 7D 7C 5C 5E 7E 5B 5D 60 шестн.) ДОЛЖНЫ быть закодированы во имя совместимости с Интернетом.
Все небезопасные символы ДОЛЖНЫ всегда быть закодированы в URL. Скажем, символ "#" ДОЛЖЕН быть закодирован в URL даже в тех программах, которым нет дела до идентификаторов фрагментов или якорей, так чтобы если URL будет скопирован в другую программу, которая использует такие идентификаторы, то изменение кодирования URL не понадобилось бы.
Многие схемы URL резервируют некоторые символы для специальных целей: придаётся определённый смысл появлению таких символов в той части URL, разбор которой зависит от конкретной схемы (в части <особая-часть> после имени схемы).
Обычно URL означает одно и то же и в том случае, когда октет представлен символом, и когда октет закодирован. Однако это не так для зарезервированных символов: кодирование символа, зарезервированного для некоторой схемы, может принести вред смысловому значению URLа, если символ использован в согласии с определённым для него смыслом. И наоборот.
Символ "?" используется как разделитель между необходимой и необязательной частью URLа. Сам разделитель НЕ ДОЛЖЕН быть закодирован. Если символ "?" появляется в любой другой части URLа, он ДОЛЖЕН быть закодирован, чтобы его нельзя было перепутать с разделителем.
Символ "=" используется как разделитель между именем параметра и его значением. Сами разделители НЕ ДОЛЖНЫ быть закодированы. Если символ "=" появляется в любой другой части URLа, тогда он ДОЛЖЕН быть закодирован, чтобы его нельзя было перепутать ни с одним из разделителей.
Символ "&" используется как разделитель между парами "параметр=значение". Сами разделители НЕ ДОЛЖНЫ кодироваться. Если символ "&" появляется в любой другой части URLа, тогда он ДОЛЖЕН быть закодирован, чтобы его нельзя было перепутать ни с одним из разделителей.
Символ "@" используется как разделитель между ареатагом и его суффиксом, или между суффиксами (см. подробности в подразделе 5.2.2.3.1). Сами разделители НЕ ДОЛЖНЫ кодироваться. Если символ "@" появляется внутри самого ареатага (или внутри суффикса), он ДОЛЖЕН быть закодирован, чтобы его нельзя было перепутать ни с одним из разделителей. В любой последующей части URLа (где появление ареатагов и суффиксов не ожидается) этот символ МОЖНО оставить как он есть.
Символ "/" зависит от схемы:
*) В некоторых схемах ("netmail:", к примеру) символ "/" имеет свой собственный (буквальный) смысл, поскольку он широко используется как часть стандартной фидонетовской записи адресов <zone>:<net>/<node>.<point> (см. подробности в FSP-1004).
*) В некоторых других схемах символ "/" зарезервирован для использования в пути к файлу (<directory>/<directory>/...<directory>/<filename>), и соответствующий ему октет (2F шестн.) ДОЛЖЕН быть закодирован, если не разделяет части пути.
См. подробности далее (в разделах, относящихся к схемам).
5.2.2.3.1 Использование доменных суффиксов в ареатагах -+----------------------------------------------------
Различные домены Фидонета (в значении "@<domain>", см. подробности в FSP-1004), также известные как Сети на Технологии Фидонета (Fidonet Technology Networks, FTN) МОГУТ иметь общие эхопочтовые области (то есть области, которые гейтуются между некоторыми из FTNов) и могут иметь внутренние эхопочтовые области (то есть области, распространяемые только внутри домена).
Если станция Фидонета имеет доступ к эхопочтовым областям из различных доменов, то ей МОГУТ встретиться области с одним и тем же именем (ареатагом) в различных доменах. И это нормально, если это одна и та же общая область; однако, даже если это разные внутренние области, у которых просто совпали имена случайно, то Единая Форма Адресации Ресурсов МОЖЕТ содержать необязательный суффикс "@<domain>" после ареатага, и тем различать между различными областями. Суффикс содержит доменное имя FTNа означенной эхообласти и предшествующий символ "@".
То же правило применяется к ареатагам файловых эх.
Доменные суффиксы специально НЕОБЯЗАТЕЛЬНЫ, поскольку FTNы обыкновенно располагают собственными средствами для того, чтобы гарантировать уникальность имён эхопочтовых областей. Некоторые FTNы, к примеру, используют свои собственные доменные имена в качестве префиксов или суффиксов для имён областей эхопочты (othernet.areaname или areaname.othernet, к примеру), тем устраняя нужду в специальном элементе URLа, который в противном случае потребовался бы для достижения той же цели.
Символ "@" является зарезервированным. Когда он используется как разделитель между ареатагом и его доменным именем FTN, символ "@" НЕ ДОЛЖЕН кодироваться. Однако если символ "@" появляется внутри самого ареатага (например, когда имя области подобно SETI@home), тогда символ ДОЛЖЕН быть кодирован, чтобы его нельзя было перепутать с разделителями.
Но вне ареатагов символ "@" не является зарезервированным, так что его МОЖНО и кодировать, и оставить как есть в любой другой части URLа (например, в пути к объекту, в имени параметра, в значении параметра, и так далее).
5.2.2.4. Плюс ("+") и кодирование пробелов -+----------------------------------------
Пробелы (октеты 20 шестн.) являются наиболее распространёнными небезопасными символами Фидонета, и оттого играют значительную роль в тех частях URLов, чьё понимание зависит от схемы: пробелы появляются в кладжах MSGID, используются в качестве разделителей между словами в текстовых строках, и так далее.
Чтобы улучшить человекочитаемость фидонетовских URLов, и чтобы сделать URLы короче, может использоваться новый более краткий синоним шестнадцатиричной тройки "%20". Это плюс ("+").
Программы, воспринимающие ту часть URLа, понимание которой зависит от конкретной схемы (это <особенная-часть>), ДОЛЖНЫ воспринимать там символ плюса ("+") как эквивалентный тройке символов, шестнадцатирично кодирующих пробел ("%20").
В силу этого обстоятельства, сам символ плюса является зарезервированным, и соответствующий ему октет (2B шестн.) ДОЛЖЕН быть закодирован, если содержится в <особенная-часть>.
5.2.2.4.1. Примечание об особенности -+----------------------------------
Правило об эквивалентности между "+" и "%20" не применяется вне той части URLа, толкование которой зависит от схемы (<особенная-часть>); символ плюса не имеет специального значения в имени самой схемы, поскольку в имени схемы пробел не допускается.
5.2.2.4.2. Примечание об интернетовском обычае -+--------------------------------------------
Этот обычай не документирован в RFC 1738. Он, однако, документирован в RFC 1630.
5.2.2.5. URLы, занимающие несколько строк текста в Фидо -+-----------------------------------------------------
Некоторые фидонетовские редакторы почты и другие элементы программного обеспечения не позволяют строкам текста быть длиннее определённого предела; например, длиннее 78 или 80 символов (или ещё меньшего предела, особенно внутри цитат). Если текст длиннее предела, то он занимает несколько строк (обычно разрыв строки вставляется вместо пробела; однако, если более чем 80 последовательных символов не содержат пробелов, строка всё равно МОЖЕТ быть разорвана. Или менее 80: предел МОЖЕТ быть разным.)
Иногда и достаточно длинному URLу МОЖЕТ оказаться необходимым также занять несколько строк. Чтобы отличать URLы, занимающие несколько строк, от URLов, которые просто кончаются (случайно) перед некоторым концом строки, нужна специальная пометка.
Два последовательных символа "%" НЕ ДОЛЖНЫ появляться в URLах (поскольку за "%" ДОЛЖНЫ следовать две шестнадцатиричные цифры), и они также редко встречаются в обычном тексте. Потому-то последовательность символов "%%" ДОЛЖНА использоваться перед и после разрыва строки в URLе, отмечая то обстоятельство, что разрывом строки не оканчивается URL.
Если синтаксический разборщик URLа встречает символьную последовательность "%%" в том URLе, который он разбирает, то разборщик ДОЛЖЕН пропустить последовательность "%%", и все символы после неё и до разрыва строки, и сам разрыв строки, и все символы после разрыва строки и до следующей последовательности "%%", и эту последовательность "%%". Затем продолжается URL.
Оформление цитаты МОЖЕТ повстречаться после разрыва строки и до последовательности "%%", означающей то место, где URL продолжается. Редакторы почты Фидонета МОГУТ передвигать последовательности "%%" и разрывы строк, когда цитируются цитаты.
Пример:
MtW>> Чтобы следить за развитием фидонетовского MtW>> программного обеспечения на русском языке, MtW>> часто используется сборник эх наподобие area://Ru.F%% MtW>> %%TN.Develop+Ru.FTN.WinSoft+Ru.FIPS/
MtW>>>>> Чтобы следить за развитием фидонетовского MtW>>>>> программного обеспечения на русском языке, MtW>>>>> часто используется сборник эх наподобие area://R%% MtW>>>>> %%u.FTN.Develop+Ru.FTN.WinSoft+Ru.FIPS/
Оформление рамки МОЖЕТ повстречаться после разрыва строки и до последовательности "%%", означающей то место, где URL продолжается, или перед разрывом строки и после последовательности "%%", означающей то место, где URL разрывается.
Пример:
+=========================================================+ + + + Чтобы следить за развитием фидонетовских программ + + на русском языке, сборник эх area://Ru.FTN.Deve%% + + %%lop+Ru.FTN.WinSoft+Ru.FIPS/ бывает весьма полезен. + + + +=========================================================+
Также возможны и любые другие виды оформления, так что синтаксический разборщик URLов ДОЛЖЕН ожидать и их. К примеру, разборщик URLов ДОЛЖЕН допускать более одного разрыва строки между рассекающими URL "%%" и следующими "%%", поскольку дополнительные разрывы строк МОГУТ быть привнесены цитированием.
НАДО позволять синтаксическому разборщику URLов отыскать, где начинается URL. Чтобы оправдать эти ожидания, URL НЕ ДОЛЖЕН быть разорван перед первым двоеточием (не только сразу перед первым двоеточием, но и где бы то ни было в имени схемы), если только URL не записан где-нибудь в таком месте, где всегда ожидается URL (к примеру, в атрибуте HREF="..." элемента LINK в HTML-эхопочте).
Фидонетовским разборщикам URLов СЛЕДУЕТ дозволять такие же, помеченные "%%", разрывы строк даже и в тех URLах, которые основаны на схемах, не определённых в стандарте FGHI URL; например, в традиционных интернетовских URLах (http://, ftp://, mailto:, news:, nntp://, и т. д.) и в современных URLах (навроде ed2k://, file://, skype:, и т. д.). Это РЕКОМЕНДУЕТСЯ, чтобы удовлетворить общую нужду в разрыве строк в URLах в фидонетовской почте, не только в URLах, относящихся к Фидонету.
Хотя другие схемы обыкновенно пользуются другими наборами зарезервированных и небезопасных символов (например, в URLах ed2k:// символ "|" не считается небезопасным, а в URLах Skype, наподобие "skype:+79184436168", символ "+" не зарезервирован), символ "%" широко используется в шестнадцатиричном кодировании октетов "%xx". Это означает, что последовательность "%%" всегда является небезопасною в таких URLах, и оттого всегда МОЖЕТ использоваться как наша собственная пометка переноса строки; это также означает, что двусмысленности "%%%" всегда МОЖНО избежать так, как описано выше.
5.3. Разбор части URLа, особенной для каждой из схем -+--------------------------------------------------
Как было объявлено выше, фидонетовские URLы записываются следующим образом:
<схема><отделитель><особая-часть>
где отделителем служит либо ":", либо "://".
В части <особая-часть> зарезервированный символ "?" служит в качестве разделителя между необходимой и необязательной частью URLа:
Необходимая часть ТРЕБУЕТСЯ. Необязательная часть МОЖЕТ быть пустою; если необязательная часть пуста, то символ "?" перед ней МОЖЕТ быть убран также. Если необязательная часть пуста, но символ "?" присутствует, то символ "?" НАДО игнорировать.
Если необязательная часть не пуста, то она состоит из одного (или более) равенств "параметр=значение", разделённых зарезервированным символом "&" следующим образом:
(в этом случае последний символ "&" НАДО игнорировать).
Ожидается, что каждое из этих равенств принимает форму "параметр=значение":
<имя параметра>=<присваемое ему значение>
Если значение не приводится, то соответствующему параметру присваивается пустое значение. В этом случае символ "=" также МОЖЕТ быть убран. Пример такой необязательной части URLа:
subject=Test&path=&subscribe&to=Test+Robot
В этом примере параметры "path" и "subscribe" становятся пустыми, параметр "subject" становится равным значению "Test", а параметр "to" принимает значение "Test Robot" (поскольку "+" представляет собою символ пробела, см. соответствующий подраздел выше).
Параметры, указываемые в необязательной части URLа, также по своей природе не являются обязательными. Если некоторый параметр вообще не указан в конкретном URLе, то принимает значение по умолчанию; а если значение по умолчанию для параметра не приведено в этом стандарте, то оно определяется либо пользовательскими настройками, либо тем, как устроен фидонетовский браузер.
Пары "параметр=значение" МОГУТ появляться в необязательной части URLа в произвольном порядке.
Например, вот такая необязательная часть URLа:
to=Test+Robot&path=&subject=Test&subscribe
является эквивалентной предыдущему примеру.
5.3.1. Обработка неуместных зарезервированных символов -+----------------------------------------------------
Зарезервированный символ "?" НЕ ДОЛЖЕН использоваться в URLе более чем единожды; если в некотором URLе много "?", то только первое появление "?" СЛЕДУЕТ рассматривать как разделитель между необходимой и необязательной частью этого URLа, а оставшиеся "?" МОГУТ восприниматься либо как если бы они были верно кодированы (символьные тройки "%3F"), либо даже игнорироваться.
Зарезервированный символ "=" НЕ ДОЛЖЕН использоваться более чем единожды в каждом из равенств с параметрами. Если в некоторой записи параметра более одного символа "=", то первый из этих символов СЛЕДУЕТ рассматривать как разделитель между именем этого параметра и значением параметра; остальные символы "=", встретившиеся до следующего символа "&" (или до конца URLа, если это последняя пара "параметр=значение") МОГУТ быть восприняты либо как если бы они были верно закодированными октетами внутри значения этого параметра (тройками "%3D"), либо даже остаться проигнорированными.
"Первое появление" означает левейшее, поскольку естественным является порядок разбора адреса в направлении слева направо.
Программы, совершающие разбор фидонетовских URLов, также МОГУТ остановить весь разбор и проигнорировать остаток URLа после той позиции, где впервые попался им неуместный зарезервированный символ. Такое поведение особенно РЕКОМЕНДУЕТСЯ для программ, пытающихся извлечь URLы из некоторого простого текста, в котором пробелы и (или) прочие разделители перед и после URLов способны подчас пропасть волею случая.
6. Схемы URLов Фидонета, означающих действия -+------------------------------------------
Схемы URLов, ниже перечисляемые, означают такие ресурсы, которые чаще всего используются в действиях, включающих составление и отсылку нетмейла или эхопочты.
В соответствии с вышележащим разделом-руководством по употреблению отделителей, символ ":" (а не тройку символов "://") СЛЕДУЕТ использовать как отделитель после части <схема> этих URLов.
6.1. Схема "netmail:" -+-------------------
Схема "netmail:" означает фидонетовский нетмейловый адрес частного лица или сервиса. Она использует стандартную фидонетовскую запись адреса, <zone>:<net>/<node>.<point>@<domain> (см. подробности в FSP-1004).
Символ "/" в этой схеме имеет своё буквальное значение.
Когда гиперссылку "netmail:" используют (щёлкают, следуют по ней), то МОЖЕТ быть запущено программное обеспечение, составляющее нетмейловые письма. Учитывая подобную возможность, несколько необязательных параметров оказались спроектированы для URLовой схемы "netmail:".
Необязательный параметр "to" указывает имя адресата нетмейла. Его значением по умолчанию МОЖЕТ быть "Sysop" или "SysOp". Его значение по умолчанию также МОЖЕТ быть определено какою-либо пользовательской настройкою в редакторе нетмейла, который используется для обработки URL "netmail:".
Необязательный параметр "subject" указывает тему (subject) составляемого нетмейла. Его значение по умолчанию является пустым; оно также МОЖЕТ быть определено пользовательской настройкою в редакторе нетмейла, который используется для обработки URL "netmail:".
Значением необязательного параметра "body" бывает означено тело (основная часть) составляемого нетмейла. (По умолчанию значение является пустым.) Программа, составляющая письмо, МОЖЕТ обернуть значение параметра "body" элементами составленного пользователем шаблона сообщений (использовать определённую пользователем подпись, приветствие и т. д.)
Ареафиксирующие письма являются специальным видом нетмейла. Такое письмо указывает узлу-аплинку (которому оно адресовано и отослано напрямую) переменить некоторые из его настроек эхопочтовой подписки. К примеру, даунлинк (который отправляет письмо) может попросить подписать или отписать себя самого от некоторых областей эхопочты, потребовать пересканирования базы сообщений, переменить настройки упаковщика и (или) распаковщика, проглядеть список доступных ему эхоконференций, и т. п.
Эхопочтовою областью называется разделяемая база сообщений, снабжённых общим ареатагом (идентификатором области) и распространяемых через Фидонет по иерархическим и (или) p2p-подобным соединениям между отдельными системами Фидонета (узловыми и пойнтовыми). См. спецификации эхопочты в FTS-0004.
Ареафиксирующие письма обычно следуют весьма жёсткой схеме: они беспременно указывают пароль даунлинка в строке темы (чтобы запрос был корректно аутентифицирован), и имя некоторого ареафиксирующего робота (например, "AreaFix", или "AreaMgr", или "AreaLink") должно быть указано в качестве имени адресата. По своей природе все эти требования секретны, и оттого вышеописанная схема "netmail:" не годится для конструирования гиперссылок, приглашающих кого-либо подписаться на некоторые фидонетовские области эхопочты или же покинуть их. Необходима отдельная схема URLов.
Схема "areafix:" означает фидонетовское ареафиксирующее действие, которое затрагивает некоторую область эхопочты, или несколько областей.
Символ "/" в этой схеме имеет своё буквальное значение.
URLы ареафикса имеют вид:
areafix:<areatag>?<необязательная-часть>
Когда гиперссылку "areafix:" используют (щёлкают мышью, следуют по ней), то СЛЕДУЕТ запуститься редактору нетмейла (или менеджеру подписки), который автоматически составляет верное ареафиксирующее письмо (адресованное узлу-аплинку и запрашивающее подписку на указанную область эхопочты). Однако РЕКОМЕНДУЕТСЯ спросить у пользователя подтверждения, отсылать ли готовый запрос о подписке или отменить его прежде, чем письмо будет отослано.
Примеры:
...если вы разработчик, подпишитесь через areafix:SU.FidoTech>https://fido.g0x.ru/?areafix:SU.FidoTech>areafix:SU.FidoTech и наслаждайтесь бесконечным потоком FAQов...
...присоединяйтесь к обсуждению жизни нынешнего Фидонета: используйте гиперссылку, ведущую на areafix:Ru.Fidonet.Today>https://fido.g0x.ru/?areafix:Ru.Fidonet.Today>areafix:Ru.Fidonet.Today
Часть <areatag> в адресе "areafix:" МОЖЕТ содержать несколько ареатагов (разделённых пробелами). В этом случае редактору нетмейла (или менеджеру подписки) НАДОБНО запросить подписку на все означенные области. Однако, в силу соображений безопасности или в силу пользовательских настроек, URLы "areafix:" МОГУТ быть полностью проигнорированы или исполнены частично (т. е. только первые N эх), если они содержат слишком много ареатагов (пользователя СЛЕДУЕТ уведомлять, когда попавшийся URL "areafix:" игнорируется или усекается).
Обыкновенно у фидонетовского программного обеспечения находятся собственные способы определить, на каком аплинке есть указанная область эхопочты и куда надо посылать ареафиксирующее письмо нетмейлом. Однако, если у системы есть несколько узлов-аплинков, способных раздавать заданную эху, то необязательный параметр "uplink" МОЖЕТ рекомендовать предпочтительный узел-аплинк (при том условии, что у автора гиперссылки есть какой-либо повод предпочесть определённый аплинк всем остальным и рекомендовать именно его).
Параметр "uplink" принимает значение, использующее стандартную фидонетовскую запись адресов, <zone>:<net>/<node>.<point>@<domain>
Однако некоторые части адреса -- "<zone>:", "@<domain>" и (или) ".<point>" -- МОГУТ пропускаться (см. подробности в FSP-1004). В значении параметра "uplink" часто опускается номер пойнта, поскольку фидонетовские пойнты практически никогда не становятся аплинками.
Примеры:
...получайте эху о встроенных системах прямо от её модератора, используйте areafix:Ru.Embedded?uplink=2:5029/32>https://fido.g0x.ru/?areafix:Ru.Embedded?uplink=2:5029/32>areafix:Ru.Embedded?uplink=2:5029/32
...эти титанические эхоконференции никогда не были на боне, используйте areafix:Titanic.PVT?uplink=2:5020/830>https://fido.g0x.ru/?areafix:Titanic.PVT?uplink=2:5020/830>areafix:Titanic.PVT?uplink=2:5020/830 и подпишитесь на одну из них с узла-первичника...
У параметра "uplink" нет значения по умолчанию; задаваемое по умолчанию поведение программного обеспечения, управляющего подпискою, должно определяться сетевой топологией отношений между аплинками и даунлинками. К примеру, если ареатаг содержит суффикс "@domain" (см. подраздел 5.2.2.3.1), то при подписке СЛЕДУЕТ выбрать аплинк, принадлежащий к заданному домену FTN, или хотя бы имеющий некоторые области эхопочти из этого домена.
Обычно, если ареафиксовый URL означает ту эхопочтовую область, на которую уже была оформлена подписка, то менеджеру подписки нечего и делать. Однако, если необязательный параметр "uplink" присутствует, то программное обеспечение МОЖЕТ прервать ранее установленную подписку на нынешнем аплинке по указанной области эхопочты, а затем обеспечить доставку той же самой области эхопочты с предпочтительного аплинка, указанного как значение параметра "uplink". (Сперва СЛЕДУЕТ спросить пользователя, уместно ли такое переназначение.)
Параметр "uplink" МОЖЕТ содержать несколько адресов, разделённых пробелами; в этом случае менеджеру подписки НАДОБНО обрабатывать их в порядке появления, хотя он МОЖЕТ предпочесть, к примеру, те адреса, с которыми есть установленная связь. Несколько областей эхопочты (обозначенные частью <areatag> URLа) МОГУТ поставляться несколькими различными аплинками (то есть даже если аплинк дан в URLе, то аплинк не обязан иметь все области эхопочты, в том же URLе перечисленные, хотя автор URLа, вероятно, веровал в то, что на каждом из этих аплинков хотя бы одна из перечисленных областей эхопочты доступна).
Информационное примечание: программное обеспечение, управляющее подпискою, МОЖЕТ игнорировать некоторые из данных аплинков, если станция Фидонета не имеет уже установленных связей с ними, или, по меньшей мере, оставить задачу для ручного вмешательства своего человека-пользователя, так как в настоящее время эхопочтовые связи между узлами не могут быть автоматически установлены. Однако, если станция Фидонета является пойнтом и данный аплинк поддерживает FSP-1016 (вывесил флаг CDP в ноудлисте), то программное обеспечение, управляющее подпискою, может создать на том узле пойнтовый AKA-адрес и установить эхопочтовую связь для данной области эхопочты. Фидонетовскому сообществу СЛЕДУЕТ разработать некоторый протокол (аналог FSP-1016), потребный для автоматического установления связей меж узлами Фидонета, и тогда использование URLов "areafix:" в гиперссылках не потребует человеческого ручного вмешательства большего, чем единственный жмяк мышою по гиперссылке.
Если <необязательная-часть> адреса areafix содержит несколько параметров "uplink", то их значения СЛЕДУЕТ объединить, как если бы адреса аплинков были бы разделены пробелами внутри единственного значения. Чтобы определить порядок их появления внутри такого объединения, пользователя МОЖНО спросить, который аплинк (или список аплинков) является наиболее желаемым.
Если и когда программное обеспечение, управляющее подпискою, добавляет новый аплинк в систему, ему НАДОБНО автоматически позаботиться обо всех потребных настройках (о настройках эхопроцессора, о настройках мейлера, об управляемых кроном скриптах создания полл-файлов, и так далее).
Если необязательный параметр "leave" появляется в ареафиксовом URLе, тогда отписка от указанной эхопочтовой области ДОЛЖНА быть запрошена вместо подписки на эту область.
Значение этого параметра игнорируется; только его присутствие или отсутствие определяет поведение менеджера подписки. РЕКОМЕНДУЕТСЯ указывать пустое значение и не использовать символ "=", тем самым удерживая длину URLов "areafix:..." в разумных пределах.
Если необязательный параметр "fecho" появляется в ареафиксовом URLе, тогда заданное имя (заданные имена) областей означают файлэхи. Так что НАДО орудовать подпискою на файлэхопочту; к примеру, менеджер подписки ДОЛЖЕН слать сообщения аплинковому FileFix вместо AreaFix, если есть в том нужда.
Фидонетовские файлэхи немного напоминают области эхопочты в смысле передачи и распространения, но в них распространяются файлы вместо сообщений. Файлэхою называется разделяемая база файлов, снабжённых общим ареатагом (идентификатором файлэхи) и распространяемых через Фидонет по иерархическим и (или) p2p-подобным соединениям между отдельными системами Фидонета (узловыми и пойнтовыми).
Значение параметра "fecho" игнорируется; только его присутствие или отсутствие определяет поведение менеджера подписки. РЕКОМЕНДУЕТСЯ указывать пустое значение и не использовать символ "=", тем самым удерживая длину URLов "areafix:..." в разумных пределах.
Будущие версии этого документа могут вводить ещё больше необязательных параметров для ареафиксовых URLов, способствуя ещё более чёткому контролю над параметрами рескана эхопочты, настройками паковщика, распаковщика, форматами архивов и т. п.
Программам, обрабатывающим ареафиксовые URLы, НЕ СЛЕДУЕТ быть уверенными насчёт того, безопасно ли игнорировать любой из им не известных параметров. Некоторые из будущих расширений могут поразительно переменить смысл URLа, как "leave" способен уже переменить этот смысл на противоположный.
Если незнакомый параметр встретился в ареафиксовом URLе, СЛЕДУЕТ всегда спрашивать пользователя о том, может ли этот параметр быть проигнорирован с лёгким сердцем.
Если ареафиксовый URL опубликован в той же области эхопочты, которой касается означенное им действие, то имя области эхопочты МОЖНО не приводить.
Примеры:
...если тебе не нравится эха, areafix:?leave>https://fido.g0x.ru/?areafix:?leave>areafix:?leave отсюда!
...если вы чувствуете, что некоторые эхопочтовые сообщения утрачены, то на нынешнего вашего аплинка нельзя полагаться. Лучше подпишитесь через areafix:?uplink=2:5063/88>https://fido.g0x.ru/?areafix:?uplink=2:5063/88>areafix:?uplink=2:5063/88
Если ареафиксовый URL опубликован в области эхопочты, имеющей то же имя, что и файлэха, которой касается означенное им действие, то это имя также МОЖНО не приводить. К примеру, в эхопочтовой области "Evil.MP3", "areafix:?fecho">https://fido.g0x.ru/?areafix:?fecho">areafix:?fecho" означает подписку на файлэху "Evil.MP3".
Если такой относительный ареафиксовый URL попался вне фидонетовской эхопочты, тогда URL неверен.
Будущие версии этого документа МОГУТ ввести такие относительные URLы "areafix:" также и в файлэхах.
6.3. Схема "echomail:" -+--------------------
Эхопочта является важной и мощной силою в Фидонете. Эхопочта, по определению, является широковещательной средою. См. спецификации эхопочты в FTS-0004.
Эхопочтовою областью называется разделяемая база сообщений, снабжённых общим ареатагом (идентификатором области) и распространяемых через Фидонет по иерархическим и (или) p2p-подобным соединениям между отдельными системами Фидонета (узловыми и пойнтовыми).
Схема "echomail:" указывает на фидонетовскую область эхопочты как на такое место, куда можно посылать эхопочту.
Символ "/" в этой схеме имеет своё буквальное значение.
Когда гиперссылку "echomail:" используют (щёлкают мышью, следуют по ней), то СЛЕДУЕТ запуститься редактору эхопочтового сообщения.
Часть <areatag> в адресе "echomail:" МОЖЕТ содержать несколько ареатагов (разделённых пробелами). В этом случае редактору эхопочты НАДОБНО использовать свои возможности кросс-постинга для рассылки желаемого сообщения во все означенные области. Однако, в силу соображений безопасности или в силу пользовательских настроек, URLы "echomail:" МОГУТ быть полностью проигнорированы или исполнены частично (т. е. только первые N эх), если они содержат слишком много ареатагов (пользователя СЛЕДУЕТ уведомлять, когда попавшийся URL "echomail:" игнорируется или усекается), или если редактор эхопочты вообще не поддерживает кросс-постинг.
Если <необязательная-часть> в URLе "echomail:" не пуста, тогда её параметры означают некоторые свойства сообщения, уготованного к отсылке. Если кросс-постинг включён, то сообщение отсылается в каждую из означенных областей после того, как пользователь его составит.
Необязательные параметры содержат лишь начальные значения этих свойств сообщения; пользователь волен отредактировать их, покуда сообщение редактируется в редакторе эхопочты.
Необязательный параметр "to" указывает имя адресата эхопочты. Его значению по умолчанию НАДОБНО быть "All", что означает всех подписчиков эхи. Значение по умолчанию МОЖЕТ также быть задано какою-либо пользовательской настройкою в редакторе эхопочты, обрабатывающем URL "echomail:".
Необязательный параметр "subject" указывает тему (subject) составляемого письма эхопочты нетмейла. Его значение является по умолчанию пустым; оно также МОЖЕТ задаваться пользовательской настройкою в том редакторе эхопочты, который используется для обработки URL "echomail:".
Значением необязательного параметра "body" бывает означено тело (основная часть) составляемой эхопочты. (По умолчанию значение является пустым.) Программа, составляющая письмо, МОЖЕТ обернуть значение параметра "body" элементами составленного пользователем шаблона сообщений (использовать определённую пользователем подпись, приветствие и т. д.)
7. Схемы URLов Фидонета, означающих объекты -+-----------------------------------------
Схемы URLов, ниже перечисляемые, означают именованные объекты, к которым можно получить доступ, прочесть их, просмотреть и т. д.
В соответствии с вышележащим разделом-руководством по употреблению отделителей, тройку символов "://" (а не символ ":") СЛЕДУЕТ использовать как отделитель после части <схема> этих URLов.
7.1. Часть адреса <путь-объекта>. Возможные формы пути -+----------------------------------------------------
Иногда Фидонет считают только текстовой сетью. По меньшей мере, Фидонет известен своими весьма невеликими средствами передачи двоичных данных. Аудитория файлэх совсем не сравнима с той, которая пользуется традиционными эхообластями; файловые запросы и аттачи практически никогда не роутятся меж узлами. В этих несколько суровых обстоятельствах, однако, существуют некоторые средства кодирования и внедрения двоичных данных внутрь текстовых сообщений. Файлы (и иногда целые директории файлов) упаковываются ради сокращения траффика; некоторые из получающихся архивов кодируются текстовыми строками, которые отсылаются при посредстве чисто текстовых средств коммуникации -- эхопочтою, нетмейлом.
Вот поэтому всем перечисленным ниже схемам фидонетовских URLов необходим какой-либо общий метод указать, при необходимости, на объект внутри упакованных (архивных) файлов и (или) внедрённый в некоторый текст. В их URLах <нужная-часть> всегда оканчивается на "/<путь-объекта>", и оттого URLы записываются таким образом:
Символ "/" всегда имеет зарезервированный смысл в части URLа <путь-объекта>; этот символ играет роль разделителя между частями пути.
Часть <путь-объекта> в URLах принимает одну из следующих форм:
<имя-объекта>
Если <путь-объекта> содержит просто имя некоторого объекта, то URLом означен именно этот объект. Сам же объект внедрён или содержится внутри ресурса, определённого остатком URLа:
<схема>://<нужная-основа>?<необязательная-часть>
<имя-объекта>/
Названный по имени объект сам является контейнером (например, упакованным архивом). URLом означен корневой каталог этого контейнера.
<имя-объекта>/<надобный-объект>
Объект <имя-объекта> является контейнером (например, упакованным архивом), чей корневой каталог содержит <надобный-объект>; URLом означен этот <надобный-объект>. Если <надобный-объект> является каталогом (то есть не файлом), то <путь-объекта> эквивалентен своей следующей форме, <имя-объекта>/<надобный-объект>/
<имя-объекта>/<надобный-объект>/
Объект <надобный-объект> внутри объекта <имя-объекта> либо сам является контейнером (например, файлом упакованного архива), либо это подкаталог внутри контейнера <имя-объекта>. URLом означено содержимое контейнера или каталога <надобный-объект>. (Если <надобный-объект> является контейнером с подкаталогами, то URLом означено содержимое его корневого каталога.)
<имя-объекта>/<элем1>/<элем2>/.../<элемN>/<надобный-объект> или <имя-объекта>/<элем1>/<элем2>/.../<элемN>/<надобный-объект>/
Объект <имя-объекта> содержит иерархию глубиною в N элементов, они являются либо подкаталогами, либо объектами-контейнерами (упакованными архивными файлами, к примеру). Необходимо войти в эти контейнеры и углубиться в каталоги, один за другим, в указанном порядке. Наивнутренний из них содержит объект <надобный-объект>. URLом означен либо сам этот объект (если нет финальной косой черты и <надобный-объект> не является подкаталогом) или его содержимое (если <надобный-объект> является подкаталогом, то означенным является содержимое этого каталога; в противном случае <надобный-объект>/ означает корневой каталог объекта <надобный-объект>).
7.1.1. Предшествующая косая черта и завершающая косая черта -+---------------------------------------------------------
Предшествующая косая черта перед путём к объекту служит лишь в качестве разделителя между двумя частями URLа (<нужная-основа> и <путь-объекта>). Если часть <путь-объекта> пуста в URLе, тогда предшествующая ей косая черта ДОЛЖНА игнорироваться программою, воспринимающей URL. Если часть <путь-объекта> пуста в URLе, то предшествующая ей косая черта МОЖЕТ быть убрана автором этого URLа, и тем самым являются эквивалентными два следующих URLа:
<схема>://<нужная-основа>/?<необязательная-часть>
<схема>://<нужная-основа>?<необязательная-часть>
Однако завершающая косая черта в пути к объекту имеет своё значение, создаёт некоторую действительную разницу. Например, "example.zip" означает сам архив (файл, который можно сохранить или переслать, и т. п.), а "example.zip/" означает корневой каталог этого архива (контейнер, который можно проглядеть, обновить, и т. п.)
Завершающая косая черта после пути к объекту НЕ ДОЛЖНА быть проигнорирована.
Подчас <путь-объекта> указывает на объект внутри такого контейнера, который некоторым фидонетовским браузерам не под силу открыть самостоятельно. Это МОЖЕТ случиться, когда формат архива неизвестен (или известен, но новее, нежели поддерживаемая его версия).
Если объект этот запрошен как самостоятельная сущность (скажем, если его URL введён в адресной строке фидонетовского браузера, или если пользователь перешёл по такой гиперссылке, где этот URL указан), то браузер МОЖЕТ осведомить пользователя о неведомом повстречавшемся контейнере, и предложить сохранение контейнера для возможного анализа вручную (в конце концов, пользователь может располагать такими средствами распаковки, которые ещё не были интегрированы в фидонетовский браузер, и может желать опробовать их).
Если запрошенный объект не является самостоятельной сущностью (например, если это всего лишь одно из изображений на странице гипертекста), если много таких объектов запрашиваются в одно и то же время с одной и той же целью, тогда не было бы мудро утопить пользователя потоком сведений о каждом из таких, одновременно наблюдающихся, препятствий; и потому браузеру НАДОБНО следовать своим стандартным процедурам, предусмотренным на случай ошибки (показать значок "разбитой картинки", или использовать альтернативный объект, или альтернативный текст, если он приведён).
7.2. Схема "area://" -+------------------
Эхопочта является важной и мощной силою в Фидонете. Эхопочта, по определению, является широковещательной средою. См. спецификации эхопочты в FTS-0004.
Эхопочтовою областью называется разделяемая база сообщений, снабжённых общим ареатагом (идентификатором области) и распространяемых через Фидонет по иерархическим и (или) p2p-подобным соединениям между отдельными системами Фидонета (узловыми и пойнтовыми).
В силу неотъемлемо присущей фидонетовским программным пакетам модульности, редактор эхопочты и браузер эхопочты могут быть различными программами (к примеру, браузеру не необходим доступ на запись к базе сообщений, и он может работать через read-only гейт). Схема "echomail:" (определённая выше) предназначена означать действие фидонетовского редактора эхопочты; схема "area://", определяемая в этом разделе, означает ресурс, расположенный в базе сообщений эхоконференции. Эти схемы могут обслуживаться разными модулями программного обеспечения, даже если они были изготовлены независимо.
Символ "/" имеет своё буквальное значение в необязательной части URLов этой схемы. Символ "/" имеет зарезервированный смысл внутри требуемой части URLа (<areatag>/<путь-объекта>), играя роль разделителя между частями пути. Если <areatag> (ареатаг эхи) содержит символ "/" в его буквальном значении, то этот символ ДОЛЖЕН быть кодирован.
Если <areatag> пуст, то <путь-объекта> ДОЛЖЕН также быть пуст; такой URL ведёт ко списку доступных областей эхопочты, также известному как ареалист.
Примеры:
area:// area:/// area://?
Если <путь-объекта> пуст, а <areatag> не пуст, то URL определяет набор (множество) эхопочтовых сообщений. В зависимости от URL, это множество МОЖЕТ содержать единственное сообщение, или несколько сообщений, или вообще ни одного сообщения. Часть URLа <areatag> определяет первоначальное множество сообщений, которое затем фильтруется (см. раздел 7.2.1 ниже), и фильтрованные множества сообщений комбинируются, формируя итоговое множество сообщений, которое наконец и является желаемым ресурсом, который означен данным URLом.
Если <areatag> содержит только один ареатаг, тогда первоначальное множество сообщений ДОЛЖНО состоять из всех сообщений эхопочтовой области, соответствующей данному ареатагу.
Однако, <areatag> в URLе "area://" МОЖЕТ содержать несколько ареатагов (разделённых пробелами). В этом случае первоначальное множество сообщений ДОЛЖНО состоять из всех сообщений изо всех эхопочтовых областей, помеченных данными ареатагами.
Любой из ареатагов МОЖЕТ содержать суффикс "@domain" (см. раздел 5.2.2.3.1).
Если ареатаг соответствует эхопочтовой области, которой нету в системе, тогда первоначальное множество сообщений не будет полным, и браузеру Фидонета СЛЕДУЕТ отобразить об этом некоторое предупреждение. К примеру, предупреждение может содержать URL вида areafix:ареатаг и пользователя МОЖНО спросить, не желает ли он подписаться и сделать рескан на отстутствующую эхоконференцию от аплинка. Предупреждение особенно РЕКОМЕНДУЕТСЯ, если все указанные ареатаги соответствуют отсутствующим эхам.
Любой из URLов вида areafix:ареатаг в таком предупреждении, если присутствует, ДОЛЖЕН сохранять суффиксы "@domain", данные в URLе "area://" для отсутствующих областей.
(Если <путь-объекта> пуст и <необязательная-часть> не содержит фильтров сообщений, то URLом area означена вся эхоконференция целиком.
В этом случае, если эхоконференции нету в системе, браузер МОЖЕТ перенаправить пользователя на какое-либо внешнее хранилище эхопочты, такое как WebBBS или зеркало Usenet.)
Итоговое множество сообщений, определённое URLом, также ДОЛЖНО быть сформировано, если <путь-объекта> не пуст. Однако, в этом случае не само итоговое множество является означенным; в этом случае URL с существующей частью <путь-объекта> соответствует некоторому объекту, содержащемуся в итоговом множестве сообщений. (См. подраздел 7.2.2.2, в котором объяснено, как определяется означенный объект.)
7.2.1. Фильтры сообщений -+----------------------
URL возможно составить таким образом, чтобы он означал не всю эхопочтовую область (области), а более узкое подмножество её(их) сообщений. Специальные необязательные параметры, так называемые фильтры сообщений, используются для этой цели в URLах. Они содержат особенные свойства желаемых сообщений: это может быть источник сообщения, или интервал даты и времени, или некоторый текстовый фрагмент (более или менее уникальный), или кладж.
Если хотя бы один из фильтров сообщений присутствует в необязательной части area-адреса, тогда
area://<areatag>?<необязательная-часть>
означает не всю базу сообщений заданной эхи, а лишь некоторое подмножество её сообщений; это подмножество определяется указанным значением фильтра сообщений (или нескольких фильтров).
Если <необязательная-часть> содержит только один фильтр, тогда итоговое множество сообщений (означенное URLом) равняется фильтрованному множеству, указанному единственным фильтром.
Если <необязательная-часть> содержит несколько фильтров, тогда итоговое множество является комбинацией отдельных фильтрованных множеств, указанных отдельными фильтрами. Комбинируясь, они формируют или объединения, или пересечения.
В теории множеств и других отраслях математики, объединением множеств называется такое множество, которое содержит всё принадлежащее к любому из множеств, но ничего более. Если A и B -- множества, то объединением A и B называют множество, содержащее все элементы A и все элементы B, но никаких других элементов не содержащее.
Пересечением двух множеств A и B называется множество, которое содержит все те элементы A, которые также принадлежат B (или, что то же самое, все элементы B, которые также принадлежат A), а никаких других элементов не содержит.
Так как фильтры являются необязательными параметрами, то они появляются в форме "параметр=значение". Именем параметра является тип фильтра:
<тип фильтра>=<значение>
Несколько фильтров одного и того же типа МОГУТ появляться в одном и том же URLе.
Чтобы сформировать итоговое множество сообщений, определённое URLом, требуются следующие два шага:
1) Фильтрованные множества, определённые фильтрами сообщений одного и того же типа, комбинируются. В зависимости от типа (см. подробности ниже), они формируют либо объединения, либо пересечения, ниже называемые типовыми множествами подытога. Для каждого из типов фильтров сообщений, ниже описанных (в подразделе 7.2.1.1, в подразделе 7.2.1.2, и т. д.), формируется своё отдельное типовое множество подытога.
2) Типовые множества подытога различных типов фильтров (сформированные предыдущим шагом) комбинируются, и они формируют итоговое множество сообщений. Оно всегда ДОЛЖНО быть пересечением подытогов, так что итоговое множество содержит только сообщения, принадлежащие к каждому из типовых множеств подытога.
ОСТОРОЖНО! Типы фильтров, отсутствующие в заданном URLе, НЕ ДОЛЖНЫ приниматься во внимание: если к некоторому типу фильтров не принадлежит ни один из фильтров, указанных в заданном URLе, то соответствующее типовое множество подытога (для этого типа фильтров) является пустым, но это пустое множество ДОЛЖНО игнорироваться при формировании итогового пересечения. (В противном случае итоговое множество сообщений было бы пустым всякий раз, если только не присутствует каждый из возможных типов фильтров; а не таковы наши намерения.) Однако типовое множество подытога МОЖЕТ быть пустым для присутствующего типа фильтров; в этом случае пустое множество НЕ ДОЛЖНО игнорироваться. Поэтому-то и нужно осторожно отличать пустые множества от отсутствующих типов и пустые множества, вычисленные в качестве типовых множеств подытога для присутствующих типов фильтров.
(К примеру, если URL не содержит фильтров типа "msgid", тогда типовое множество подытога для типа "msgid" пусто, но оно игнорируется; однако если URL содержит один фильтр "msgid", содержащий идентификатор, соответствующий отсутствующему сообщению, то пустое типовое множество подытога для типа "msgid" приводит к пустому итоговому множеству сообщений.)
СОВЕТ ПО ИСПОЛНЕНИЮ: скорость вычисления МОЖЕТ быть улучшена самим фактом того, что итоговое множество всегда является пересечением типовых множеств подытога. Сообщение ДОЛЖНО появиться в каждом из типовых множеств подытога, чтобы стать частью итогового множества. И поэтому, если одно из типовых множеств подытога уже вычислено, все остальные фильтры сообщений МОЖНО применять к этому типовому множеству подытога вместо первоначального множества сообщений: вполне безопасно пропускать те сообщения, которые имеются в первоначальном множестве сообщений, но отсутствуют в этом типовом множестве подытога, поскольку они в любом случае не появятся в итоговом множестве сообщений.
Пример: если заданный URL содержит несколько фильтров типа "msgid" и несколько фильтров типа "find", тогда разумно начать с вычисления типового множества подытога для типа "msgid" (оно, скорее всего, будет содержать всего-то несколько сообщений); затем вполне безопасным будет применение поисков "find" только к сообщениям этого более узкого множества, что избавит нас от надобности проглядывать через всё первоначальное множество.
7.2.1.1. Фильтры типа "msgid" -+---------------------------
Фильтр "msgid" позволяет указать на единственное сообщение в заданной эхопочтовой области (областях). Значение такого параметра содержит содержимое кладжа MSGID из этого сообщения, но без предшествующей строки "^MSGID: ".
Кладжи MSGID определены в FTS-0009 и хорошо служат в качестве уникальных идентификаторов для сообщений эхопочты.
Сообщение из первоначального множества сообщений появляется в фильтрованном множестве (определённом фильтром "msgid") тогда и только тогда, когда сообщение содержит кладж MSGID, совпадающий со значением фильтра.
Вероятнее всего, фильтрованное множество содержит лишь одно сообщение. Оно МОЖЕТ содержать несколько сообщений, поскольку хотя FTS-0009 заявляет, что два сообщения с одной системы НЕ МОГУТ иметь один и тот же серийный номер в течение трёх лет, сама база сообщений МОЖЕТ простираться более чем на три года. В этом случае автору URLа НАДОБНО применить другие фильтры (фильтр типа "time", например), чтоб обеспечить желаемый период времени.
Отметим, что фильтр "msgid" МОЖЕТ означать такое сообщение, которое отсутствует в первоначальном множестве сообщений. В этом случае фильтрованное множество оказывается пустым. Фидонетовский браузер МОЖЕТ собирать такие события в качестве малозначительных предупреждений и МОЖЕТ реализовать некоторый пользовательский интерфейс, чтобы пользователь смог запросить на аплинке (на аплинках) рескан такой эхи (или нескольких эх), или запросить какой-либо внешний архив фидонетовских сообщений в поисках желаемых сообщений, или испробовать какие-нибудь другие средства для раздобывания желаемых сообщений.
Если <необязательная-часть> содержит несколько фильтров "msgid", тогда типовое множество подытога для типа "msgid" формируется объединением их фильтрованных множеств.
7.2.1.2. Фильтры типа "time" -+--------------------------
Фильтр "time" использует поле DateTime фидонетовских сообщений (определённое в FTS-0001) для их фильтрации, проверяя дату и (или) время, в которое сообщение было написано. Фильтрованное множество содержит только те сообщения, которые соответствуют заданному моменту времени, или принадлежат заданному интервалу времени. Содержимое фильтра "time" сложнее формата DateTime; возможные формы фильтра "time" перечисляются ниже.
Если база сообщений не использует поле DateTime как определено в FTS-0001, то аналогичная часть заголовка сообщения ДОЛЖНА использоваться для получения потребной даты и времени. Например, базы JAM используют поле DateWritten в структуре MessageFixedHeader, а базы Squish используют поле date в типе SCOMBO, и так далее. Термин "DateTime" ниже используется также и для таких случаев, это обобщение.
7.2.1.2.1. Одиночный момент -+-------------------------
Наиболее простая форма значения фильтра "time" содержит просто один момент во времени, в следующей форме:
Значение <Год> всегда ДОЛЖНО состоять и четырёх или более цифр (частью нулей, если это необходимо). Оно МОЖЕТ иметь суффикс "BC" (к примеру, "0023BC"), чтобы означать годы до нашей эры, хотя прямо сейчас нет программного обеспечения, технически способного датировать фидонетовские сообщения таким манером.
Значением <Месяц> всегда ДОЛЖНЫ быть две цифры: 01 для января, 02 для февраля, ..., 11 для ноября, 12 для декабря.
Значением <День> всегда ДОЛЖНЫ быть две цифры: 01 для первого дня месяца, 02 для второго, и так далее.
Значением <Час> всегда ДОЛЖНЫ быть две цифры, от "00" до "23".
Значением <Минута> всегда ДОЛЖНЫ быть две цифры, от "00" до "59".
Значением <Секунда> всегда ДОЛЖНЫ быть две цифры, от "00" до "60". (Значение "60" резервируется для високосных секунд, хотя они редко появляются в штампах времени в Фидо).
Сообщение из первоначального множества сообщений появляется в фильтрованном множестве (определённом заданным одиночным моментом) тогда и только тогда, если время сообщения равно значению фильтра. Проверяются все шесть значений (год, месяц, день, час, минута и секунда), если только некоторые из них в фильтре не пусты.
7.2.1.2.1.1. Пустые значения -+--------------------------
Любые из шести значений: год, месяц, день, час, минута и (или) секунда -- МОГУТ быть пустыми в этой форме фильтра и означать, что соответствующая часть DateTime у сообщения не проверяется. Соседние разделители ("/", "T", ":") МОГУТ также не приводиться; однако, чтобы поддержать некоторую разницу между внешним видом двухцифренных значений <Месяц>, <День>, <Год>, <Минута> и <Секунда>, учреждаются следующие правила.
Каждый из разделителей меж двумя непустыми соседними значениями ДОЛЖЕН присутствовать. (Это очевидно, но всё равно есть смысл упомянуть это.)
Если значение <Секунда> не пустое, то предыдущие двоеточия (":") ДОЛЖНЫ присутствовать.
Количество цифр и смысл шести значений такие же, как для одиночного момента (см. раздел 7.2.1.2.1).
Сообщение из первоначального множества сообщений появляется в фильтрованном множестве (определённом заданным верхним пределом) тогда и только тогда, если значение даты и времени сообщения не превышает значение даты и времени, заданное фильтром. Все шесть значений даты и времени сообщения (год, месяц, день, час, минута и секунда) проверяются в следующем порядке:
1) Год сообщения сравнивается с годом фильтра. Если год сообщения превышает год фильтра, то сообщение НЕ ДОЛЖНО появляться в фильтрованном множестве. Если год сообщения меньше года фильтра, то сообщение ДОЛЖНО появиться в фильтрованном множестве. Если год сообщения равняется году фильтра, переходим к следующему шагу.
2) Месяц сообщения сравнивается с месяцем фильтра. Если месяц сообщения превышает месяц фильтра, то сообщение НЕ ДОЛЖНО появляться в фильтрованном множестве. Если месяц сообщения меньше месяца фильтра, то сообщение ДОЛЖНО появиться в фильтрованном множестве. Если месяц сообщения равняется месяцу фильтра, переходим к следующему шагу.
3) День сообщения сравнивается с днём фильтра. Если день сообщения превышает день фильтра, то сообщение НЕ ДОЛЖНО появляться в фильтрованном множестве. Если день сообщения меньше дня фильтра, то сообщение ДОЛЖНО появиться в фильтрованном множестве. Если день сообщения равняется дню фильтра, переходим к следующему шагу.
4) Час сообщения сравнивается с часом фильтра. Если час сообщения превышает час фильтра, то сообщение НЕ ДОЛЖНО появляться в фильтрованном множестве. Если час сообщения меньше часа фильтра, то сообщение ДОЛЖНО появиться в фильтрованном множестве. Если час сообщения равняется часу фильтра, переходим к следующему шагу.
5) Минута сообщения сравнивается с минутою фильтра. Если минута сообщения превышает минуту фильтра, то сообщение НЕ ДОЛЖНО появляться в фильтрованном множестве. Если минута сообщения меньше минуты фильтра, то сообщение ДОЛЖНО появиться в фильтрованном множестве. Если минута сообщения равняется минуте фильтра, переходим к следующему шагу.
6) Секунда сообщения сравнивается с секундою фильтра. Если секунда сообщения превышает секунду фильтра, то сообщение НЕ ДОЛЖНО появляться в фильтрованном множестве. Если секунда сообщения меньше секунды фильтра или равняется секунде фильтра, то сообщение ДОЛЖНО появиться в фильтрованном множестве.
Первый шаг этой проверки, равно как и несколько последующих шагов, МОГУТ быть пропущены, если соответствующие наиболее левые значения пусты (см. следующий подраздел).
В отличие от формы одиночного момента, значения в форме верхнего предела у фильтра "time" НЕ МОГУТ быть пустыми в произвольном порядке; однако наиболее левые значения МОГУТ становиться пустыми слева направо, а наиболее правые значения МОГУТ становиться пустыми справа налево.
7.2.1.2.2.1. Пустые наиболее левые значения -+-----------------------------------------
Значение <Год> МОЖЕТ быть пустым, и в этом случае первый шаг описанной выше проверки ДОЛЖЕН быть пропущен, как если бы год сообщения равнялся году фильтра.
Если значение <Год> пусто, то значение <Месяц> МОЖЕТ также быть пустым, и в этом случае второй шаг описанной выше проверки также ДОЛЖЕН быть пропущен, как если бы месяц сообщения равнялся месяцу фильтра.
Если значения <Год> и <Месяц> пусты, то значение <День> МОЖЕТ также быть пустым, и в этом случае третий шаг описанной выше проверки также ДОЛЖЕН быть пропущен, как если бы день сообщения равнялся дню фильтра.
Если значения <Год> и <Месяц> и <День> пусты, то значение <Час> МОЖЕТ также быть пустым, и в этом случае четвёртый шаг описанной выше проверки также ДОЛЖЕН быть пропущен, как если бы час сообщения равнялся часу фильтра.
Если значения <Год> и <Месяц> и <День> и <Час> пусты, то значение <Минута> МОЖЕТ также быть пустым, и в этом случае пятый шаг описанной выше проверки также ДОЛЖЕН быть пропущен, как если бы минута сообщения равнялася минуте фильтра.
Чтобы выяснить, МОЖНО ли убрать разделитель ("/", или "T", или ":"), справляйтеся в подразделе 7.2.1.2.1.1: правила на этот счёт тут те же самые.
Этот URL означает сообщения, написанные (в эхопочтовой области Ru.FTN.Develop) либо прежде 18го дня любого месяца любого года, либо не позднее 15:56:54 этого 18го дня.
7.2.1.2.2.2. Пустые наиболее правые значения -+------------------------------------------
Значение <Секунда> МОЖЕТ быть пустым, и в этом случае значение <Секунда> предполагается равным 60.
Если значение <Секунда> пусто, то значение <Минута> также МОЖЕТ быть пустым, и в этом случае значение <Минута>:<Секунда> предполагается равным 59:60.
Если значения <Секунда> и <Минута> пусты, то значение <Час> также МОЖЕТ быть пустым, и в этом случае значение <Час>:<Минута>:<Секунда> предполагается равным 23:59:60.
Если значения <Секунда> и <Минута> и <Час> пусты, то значение <День> также МОЖЕТ быть пустым, и в этом случае значение <День>T<Час>:<Минута>:<Секунда> предполагается равным 31T23:59:60.
Если значения <Секунда> и <Минута> и <Час> и <День> пусты, то значение <Месяц> также МОЖЕТ быть пустым, и в этом случае значение <Месяц>/<День>T<Час>:<Минута>:<Секунда> предполагается равным 12/31T23:59:60.
Ни одно из вышеперечисленных предполагаемых значений не потерпит неудачу в соответствующих им шагах описанной выше проверки; соответствующие шаги СЛЕДУЕТ просто пропускать, если наиболее правые значения пусты: если этакий шаг достигнут после предыдущих шагов, тогда проверенное сообщение ДОЛЖНО появиться в фильтрованном множестве.
Наиболее левые и наиболее правые значения МОГУТ быть пусты одновременно; однако, некоторые непустые значения (лишь одно, или более) ДОЛЖНЫ появляться в этой форме фильтра.
Чтобы выяснить, МОЖНО ли убрать разделитель ("/", или "T", или ":"), справляйтеся в подразделе 7.2.1.2.1.1: правила на этот счёт тут те же самые.
Количество цифр и смысл шести значений такие же, как для одиночного момента (см. раздел 7.2.1.2.1).
Сообщение из первоначального множества сообщений появляется в фильтрованном множестве (определённом заданным нижним пределом) тогда и только тогда, если значение даты и времени сообщения не оказывается меньше значения даты и времени, заданного фильтром. Все шесть значений даты и времени сообщения (год, месяц, день, час, минута и секунда) проверяются в следующем порядке:
1) Год сообщения сравнивается с годом фильтра. Если год сообщения превышает год фильтра, то сообщение ДОЛЖНО появляться в фильтрованном множестве. Если год сообщения меньше года фильтра, то сообщение НЕ ДОЛЖНО появиться в фильтрованном множестве. Если год сообщения равняется году фильтра, переходим к следующему шагу.
2) Месяц сообщения сравнивается с месяцем фильтра. Если месяц сообщения превышает месяц фильтра, то сообщение ДОЛЖНО появляться в фильтрованном множестве. Если месяц сообщения меньше месяца фильтра, то сообщение НЕ ДОЛЖНО появиться в фильтрованном множестве. Если месяц сообщения равняется месяцу фильтра, переходим к следующему шагу.
3) День сообщения сравнивается с днём фильтра. Если день сообщения превышает день фильтра, то сообщение ДОЛЖНО появляться в фильтрованном множестве. Если день сообщения меньше дня фильтра, то сообщение НЕ ДОЛЖНО появиться в фильтрованном множестве. Если день сообщения равняется дню фильтра, переходим к следующему шагу.
4) Час сообщения сравнивается с часом фильтра. Если час сообщения превышает час фильтра, то сообщение ДОЛЖНО появляться в фильтрованном множестве. Если час сообщения меньше часа фильтра, то сообщение НЕ ДОЛЖНО появиться в фильтрованном множестве. Если час сообщения равняется часу фильтра, переходим к следующему шагу.
5) Минута сообщения сравнивается с минутою фильтра. Если минута сообщения превышает минуту фильтра, то сообщение ДОЛЖНО появляться в фильтрованном множестве. Если минута сообщения меньше минуты фильтра, то сообщение НЕ ДОЛЖНО появиться в фильтрованном множестве. Если минута сообщения равняется минуте фильтра, переходим к следующему шагу.
6) Секунда сообщения сравнивается с секундою фильтра. Если секунда сообщения меньше секунды фильтра, то сообщение НЕ ДОЛЖНО появляться в фильтрованном множестве. Если секунда сообщения превышает секунду фильтра или равняется секунде фильтра, то сообщение ДОЛЖНО появиться в фильтрованном множестве.
Первый шаг этой проверки, равно как и несколько последующих шагов, МОГУТ быть пропущены, если соответствующие наиболее левые значения пусты (см. следующий подраздел).
В отличие от формы одиночного момента, значения в форме нижнего предела у фильтра "time" НЕ МОГУТ быть пустыми в произвольном порядке; однако наиболее левые значения МОГУТ становиться пустыми слева направо, а наиболее правые значения МОГУТ становиться пустыми справа налево.
7.2.1.2.3.1. Пустые наиболее левые значения -+-----------------------------------------
Значение <Год> МОЖЕТ быть пустым, и в этом случае первый шаг описанной выше проверки ДОЛЖЕН быть пропущен, как если бы год сообщения равнялся году фильтра.
Если значение <Год> пусто, то значение <Месяц> МОЖЕТ также быть пустым, и в этом случае второй шаг описанной выше проверки также ДОЛЖЕН быть пропущен, как если бы месяц сообщения равнялся месяцу фильтра.
Если значения <Год> и <Месяц> пусты, то значение <День> МОЖЕТ также быть пустым, и в этом случае третий шаг описанной выше проверки также ДОЛЖЕН быть пропущен, как если бы день сообщения равнялся дню фильтра.
Если значения <Год> и <Месяц> и <День> пусты, то значение <Час> МОЖЕТ также быть пустым, и в этом случае четвёртый шаг описанной выше проверки также ДОЛЖЕН быть пропущен, как если бы час сообщения равнялся часу фильтра.
Если значения <Год> и <Месяц> и <День> и <Час> пусты, то значение <Минута> МОЖЕТ также быть пустым, и в этом случае пятый шаг описанной выше проверки также ДОЛЖЕН быть пропущен, как если бы минута сообщения равнялася минуте фильтра.
Чтобы выяснить, МОЖНО ли убрать разделитель ("/", или "T", или ":"), справляйтеся в подразделе 7.2.1.2.1.1: правила на этот счёт тут те же самые.
Этот URL означает сообщения, написанные (в эхопочтовой области Ru.FTN.Develop) либо позднее 18го дня любого месяца любого года, либо не ранее 15:56:54 этого 18го дня.
7.2.1.2.3.2. Пустые наиболее правые значения -+------------------------------------------
Значение <Секунда> МОЖЕТ быть пустым, и в этом случае значение <Секунда> предполагается равным 00.
Если значение <Секунда> пусто, то значение <Минута> также МОЖЕТ быть пустым, и в этом случае значение <Минута>:<Секунда> предполагается равным 00:00.
Если значения <Секунда> и <Минута> пусты, то значение <Час> также МОЖЕТ быть пустым, и в этом случае значение <Час>:<Минута>:<Секунда> предполагается равным 00:00:00.
Если значения <Секунда> и <Минута> и <Час> пусты, то значение <День> также МОЖЕТ быть пустым, и в этом случае значение <День>T<Час>:<Минута>:<Секунда> предполагается равным 01T00:00:00.
Если значения <Секунда> и <Минута> и <Час> и <День> пусты, то значение <Месяц> также МОЖЕТ быть пустым, и в этом случае значение <Месяц>/<День>T<Час>:<Минута>:<Секунда> предполагается равным 01/01T00:00:00.
Ни одно из вышеперечисленных предполагаемых значений не потерпит неудачу в соответствующих им шагах описанной выше проверки; соответствующие шаги СЛЕДУЕТ просто пропускать, если наиболее правые значения пусты: если этакий шаг достигнут после предыдущих шагов, тогда проверенное сообщение ДОЛЖНО появиться в фильтрованном множестве.
Наиболее левые и наиболее правые значения МОГУТ быть пусты одновременно; однако, некоторые непустые значения (лишь одно, или более) ДОЛЖНЫ появляться в этой форме фильтра.
Чтобы выяснить, МОЖНО ли убрать разделитель ("/", или "T", или ":"), справляйтеся в подразделе 7.2.1.2.1.1: правила на этот счёт тут те же самые.
(последовательность символов "%%" используется здесь для обозначения того места, где разрыв строки появляется внутри URLа, а затем того места, где URL продолжается; см. подробнее в разделе 5.2.2.5).
Сообщение из первоначального множества сообщений появляется в фильтрованном множестве (определённом заданным интервалом времени) тогда и только тогда, когда дата и время сообщения соответствует обоим данным пределам, как указано в разделах 7.2.1.2.2 и 7.2.1.2.3.
7.2.1.2.4.1. Пустые наиболее правые значения -+------------------------------------------
Наиболее правые значения в каждом из сочетаемых пределов МОГУТ быть пустыми в направлении справа налево (<Секунда>, или <Секунда> и <Минута>, или <Секунда> и <Минута> и <Час> и т. д.).
Чтобы выяснить, МОЖНО ли убрать разделитель ("/", или "T", или ":"), справляйтеся в подразделе 7.2.1.2.1.1: правила на этот счёт тут те же самые.
Предполагается, что пустые наиболее правые значения нижнего предела являются наименьшими из возможных (см. раздел 7.2.1.2.3.2). Предполагается, что пустые наиболее правые значения верхнего предела являются набольшими из возможных (см. раздел 7.2.1.2.2.2).
(последовательность символов "%%" используется здесь для обозначения того места, где разрыв строки появляется внутри URLа, а затем того места, где URL продолжается; см. подробнее в разделе 5.2.2.5).
7.2.1.2.4.2. Пустые наиболее левые значения -+-----------------------------------------
Количество пустых наиболее левых значений в части <НижнийПредел> значения фильтра НЕ ДОЛЖНО превышать количества пустых наиболее левых значений в части <ВерхнийПредел>.
Если такое значение является пустым в обеих частях (в <НижнийПредел> и в <UpperLimit>), то соответствующее значение у сообщения не проверяется (см. раздел 7.2.1.2.2.1 и раздел 7.2.1.2.3.1).
Этот URL означает сообщения, написанные (в эхопочтовой области Ru.FTN.Develop) до полудня в любой день. (Значения <Год> и <Месяц> и <День> пусты в обеих частях значения фильтра.)
Если такое значение является пустым только в <ВерхнийПредел>, то это значение ДОЛЖНО приниматься равным соответствующему значению части <НижнийПредел>.
Наиболее левые и наиболее правые значения МОГУТ быть пусты одновременно; однако, некоторые непустые значения (лишь одно, или более) ДОЛЖНЫ появляться в каждой части (в <НижнийПредел> и в <ВерхнийПредел>) этой формы фильтра. (В предыдущем примере, <Час> и <Минута> и <Секунда> пусты в каждой части, в качестве наиболее правых; а <Год> и <Месяц> пусты в <ВерхнийПредел>, в качестве наиболее левых.)
Чтобы выяснить, МОЖНО ли убрать разделитель ("/", или "T", или ":"), справляйтеся в подразделе 7.2.1.2.1.1: правила на этот счёт тут те же самые.
Этот вариант значения фильтра "time" являтся разделённым пробелами списком из одного или более вышеприведённых вариантов: одиночных моментов, и (или) верхних пределов, и (или) нижних пределов, и (или) интервалов времени.
Сообщение из первоначального множества сообщений появляется в фильтрованном множестве (определённом заданным комплексом) тогда и только тогда, если оно появляется хотя бы в одном из отдельных фильтрованных множеств, определённых разделёнными пробелами подфильтрами. Другими словами, фильтрованное множество комплексного фильтра "time" является объединением множеств, определённых его подфильтрами.
7.2.1.2.7. Порядковый номер дня в году -+------------------------------------
В каждой из перечисленных выше форм фильтра "time", если оба значения <Месяц> и <День> не пусты, состоящий из трёх цифр порядковый номер для в году МОЖЕТ заменить часть "<Месяц>/<День>" в значении фильтра: "001" МОЖЕТ заменить "01/01", "002" МОЖЕТ заменить "01/02", ..., "031" МОЖЕТ заменить "01/31", "032" МОЖЕТ заменить "02/01", и так далее, в соответствии с нижеследующей таблицей:
Имя месяца <Месяц>/<День> Порядковый номер дня в году в обычные годы: в високосные:
Январь 01/01-01/31 001-031 001-031
Февраль 02/01-02/28 032-059 032-060 (но -02/29 в високосные годы)
Март 03/01-03/31 060-090 061-091
Апрель 04/01-04/30 091-120 092-121
Май 05/01-05/31 121-151 122-152
Июнь 06/01-06/30 152-181 153-182
Июль 07/01-07/31 182-212 183-213
Август 08/01-08/31 213-243 214-244
Сентябрь 09/01-09/30 244-273 245-274
Октябрь 10/01-10/31 274-304 275-305
Ноябрь 11/01-11/30 305-334 306-335
Декабрь 12/01-12/31 335-365 336-366
Те правила, которые определяют, МОГУТ ли другие значения и (или) разделители быть пропущенными, остаются такими же, как если бы присуствовали непустые значения "<Месяц>/<День>" с косой чертою меж ними.
Такая форма URLа МОЖЕТ сгодиться для устройств и (или) для элементов программного обеспечения, недостаточно разумных для того, чтобы справиться со всем календарём с его двенадцатью месяцами, и оттого не способных создавать более сложные URLы.
7.2.1.2.8. Использование текущей даты и времени -+---------------------------------------------
Значение "now" (независимо от регистра; даже "NOw" возможно) МОЖЕТ использоваться в том месте, где ожидается значение <Год> и (или) <Месяц> и (или) <День> и (или) <Час> и (или) <Минута> и (или) <Секунда>. Программное обеспечение, обрабатывающее URL, ДОЛЖНО подставить соответствующий компонент текущей даты или текущего времени вместо исходного значения "now".
К примеру, если URL обрабатывается около самого полудня, то
Порядковый номер дня в году (см. раздел 7.2.1.2.7) НЕ МОЖЕТ заменяться на "now"; используйте "now/now" вместо него, чтоб подставить пару из текущего месяца и текущего дня.
Если на значение "now" заменяется <Год> и (или) <Месяц> и (или) <День>, тогда каждая из косых черт ("/"), которые используются в качестве разделителей, НЕ ДОЛЖНА пропускаться в дате. (Это ТРЕБУЕТСЯ для различения внешнего вида разных элементов даты, поскольку всего одной косой черты, как в "now/", недостаточно для того, чтобы судить, значение ли это года или значение месяца.)
Кладжи (также известные под названием кладжевых строк или управляющих параграфов) -- это специальные строки, внедряемые в текстовое тело фидонетовского сообщения. Иногда кладжи обеспечивают поддержку новой адресации и другой управляющей информации, иногда они содержат элементы вспомогательных сведений об авторе сообщения (его местонахождение, номер ICQ, Jabber ID, реальное имя, играющая музыка, настроение, и т. п.). См. технические подробности в FTS-4000.
И чтобы поддержать новую адресацию (поддержать использование фильтров "time" в URLах FGHI), вводится новый кладж. Его строка имеет следующий формат:
Здесь <SOH> является одиночным символом SOH (Ctrl+A, ASCII 1); значения <Год> и <Месяц> и <День> и <Час> и <Минута> и <Секунда> определяют тот одиночный момент (см. раздел 7.2.1.2.1), к которому приписывается сообщение.
Этот метод приписки превосходит поле DateTime в заголовке сообщения. Если сообщение содержит кладж TrueTime, то только содержимое этого кладжа ДОЛЖНО проверяться на соответствие повстречавшимся фильтрам "time", когда решается, появится ли сообщение из первоначального множества сообщений в фильтрованном множестве (определённом заданным фильтром "time").
Значения <Год> и <Месяц> и <День> и <Час> и <Минута> и <Секунда> НЕ ДОЛЖНЫ быть пустыми в кладже TrueTime; разделители меж ними также ДОЛЖНЫ присутствовать.
Кладжи TrueTime НЕ ДОЛЖНЫ использовать порядковый номер дня в году (раздел 7.2.1.2.7). Кладжи TrueTime НЕ ДОЛЖНЫ использовать значение "now" (раздел 7.2.1.2.8).
Если автор некоторого сообщения желает приписать его текст (или, говоря в общих терминах, его материал) к некоторому моменту времени, серьёзно отличающемуся от текущего времени, автору СЛЕДУЕТ использовать кладж TrueTime для указания желаемого времени, а текущее время в заголовке сообщения оставить нетронутым. В противном случае сообщение МОЖЕТ быть потеряно при передаче, и по уважительной причине: какой-либо эхопроцессор (тоссер) МОЖЕТ рассудить, что это баг в старом архиве сообщений, например.
Нынешняя практика Фидонета предполагает указание местного времени сообщений, и этот документ предполагает, что значение фильтра "time" сверяется с местным временем сообщений. Это поведение по умолчанию.
Однако, если необязательный параметр "usetz" присутствует в URLе, то синтаксический разборщик URLа ДОЛЖЕН предполагать, что значения всех фильтров "time", присутствующих в том же URLе, заданы в UTC, и что их НАДО сверять с UTC сообщений. Чтобы вычислить UTC сообщений, принадлежащих к первоначальному множеству сообщений, СЛЕДУЕТ использовать соответствующий кладж TZUTC или TZUTCINFO (см. подробности в FTS-4008), хотя фидонетовские браузеры МОГУТ использовать некоторые другие средства для получения часового пояса сообщений (например, они МОГУТ просто читать подполя TZUTCINFO в базах JAM, если используются эти базы).
Если необязательный параметр "usetz" присутствует в URLе, то значения "now" (см. раздел 7.2.1.2.8) ДОЛЖНЫ подставляться в текущем UTC.
Необязательный параметр "usetz" также управляет тем, какие сообщения соответствуют каким датам в календарном виде (см. раздел 7.2.3.14): если параметр присутствует, тогда UTC используется при построении календарного вида.
Необязательный параметр "usetz" также используется при сортировке, когда определяется хронологический порядок сообщений (см. раздел 7.2.6.3): если присутствует "usetz", то сообщения сортируются по их UTC вместо местного времени.
7.2.1.2.11. Будущие варианты фильтров "time" -+-----------------------------------------
Будущие версии этого документа МОГУТ вводить некоторые другие форматы даты и времени, чтобы указывать день недели, дни относительно Пасхи и т. п.
Программам, обрабатывающим фильтры "time", НЕ СЛЕДУЕТ быть уверенными насчёт того, безопасно ли игнорировать любой из не известных им фильтров. Если повстречался неизвестный формат даты и (или) времени, СЛЕДУЕТ всегда спрашивать пользователя, возможно ли проигнорировать такой фильтр "time" с лёгким сердцем.
7.2.1.3. Фильтры типа "from" -+--------------------------
Фильтр "from" содержит фидонетовский нетмейловый адрес частного лица или сервиса. Сообщение из первоначального множества сообщений появляется в фильтрованном множестве (определённом заданным адресом) тогда и только тогда, когда это сообщение происходит с указанного адреса.
Значение фильтра "from" использует стандартную фидонетовскую запись адреса, <zone>:<net>/<node>.<point>@<domain> (см. подробности в FSP-1004).
Если в необязательной части area-адреса присутствуют несколько фильтров "from", то типовое множество подытога фильтров "from" является объединением фильтрованных множеств, определённых фильтрами "from".
7.2.1.3.1. Фильтры типа "twit" -+----------------------------
Фильтры типа "twit" подобны отрицательным "from" (т. е. фильтры "from" определяют, чьи сообщения желательны, а фильтры "twit" определяют, чьи сообщения нежелательны). Однако тип фильтров "twit" является отдельным и формирует своё собственное типовое множество подытога из фильтрованных сообщений.
Значение фильтра "twit" содержит разделяемый пробелами список фидонетовских нетмейловых адресов. Сообщение из первоначального множества сообщений появляется в фильтрованном множестве (определённом заданным фильтром "twit") тогда и только тогда, когда это сообщение не происходит ни с одного из адресов, данных в значении фильтра.
Адреса в значении фильтра "twit" использует стандартную фидонетовскую запись адреса, <zone>:<net>/<node>.<point>@<domain> (см. подробности в FSP-1004).
Если в необязательной части URLа присутствуют несколько фильтров "twit", то типовое множество подытога фильтров "twit" является пересечением фильтрованных множеств, определённых фильтрами "twit" (т. е. разделённые пробелами списки в нескольких фильтров этого типа применяются так, как если бы они были разделены пробелами внутри единственного фильтра).
Фидонетовский браузер МОЖЕТ вообще игнорировать фильтры "twit" в соответствии с пользовательскими настройками браузера, хотя тогда фильтрованное множество сообщений становится шире, нежели автор URLа изначально намеревался. Вероятно, разумнее дать пользователю некоторую возможность (например, через контекстное меню адресной строки браузера, в которой располагаются URLы) включать и выключать фильтры "twit", и, возможно, возможность импортировать некоторые отдельные адреса из фильтра (фильтров) "twit" URLа в свой пользовательский постоянно действующий список твитов.
7.2.1.4. Фильтры типа "find" -+--------------------------
Фильтр "find" подразумевает, что в означенной эхообласти следует отыскать конкретное сообщение или несколько сообщений. Значение фильтра "find" содержит либо регулярное выражение, либо простой текст; сообщение из первоначального множества сообщений появляется в фильтрованном множестве (определённом заданным регулярным выражением или простым текстом) тогда и только тогда, когда тело этого сообщения соответствует заданному выражению или заданному тексту.
Значение фильтра "find" ДОЛЖНО рассматриваться в качестве регулярного выражения тогда и только тогда, когда его первым символом является косая черта (символ "/"). Если это не так, то значением фильтра "find" является простой текст.
Язык регулярных выражений весьма строг, точен, сложен и могуч. Он обыкновенно используется, чтобы в точности задать условия, которым текст должен соответствовать, когда совпадение становится успешным. (Подробности о регулярных выражениях см. в приложении A.)
Примеры регулярных выражений:
код в URLе: ...&find=/\bFido(net)%3f\b/i выражение: /\bFido(net)?\b/i находит: Fido находит: FIDOnet находит: FidoNet не находит: Fidonet-alike не находит: Fidobrowser не находит: fidoshnik не находит: triffidos
код в URLе: ...&find=/(P(2P)%7b1,4%7d%7cfile\s%2bexchange)/ выражение: /(P(2P){1,4}|file\s+exchange)/ находит: P2P находит: P2P2P2P находит: P2P2P2P2P находит: file exchange находит: file exchange не находит: P2P2P2P2PP2P2P2P2P не находит: P2P2P2P2P2P не находит: fileexchange не находит: file_exchange не находит: p2p не находит: FiLe ExChanGe
Фидонетовские сообщения способны содержать кладжи (технические подробности см. в FTS-4000.). Стало быть, URL способен указать на выборку сообщений, отмеченных некоторым типом кладжа или некоторыми значениями кладжа. Соответствующее регулярное выражение начинается с символов ^\x1 или ^\01, которые обозначают начало строки с непосредственно следующим за ним символом SOH (Ctrl+A, ASCII 1). Выражение всегда использует многострочный режим поиска совпадений (см. в приложении A); так что конструкция "^" срабатывает в начале каждого кладжа.
Примеры регулярных выражений:
код URLа: ...&find=/%5E\01Real\s*name:\s%2B(%3f!\s).%2b/i выражение: /^\01Real\s*name:\s+(?!\s).+/i
Соответствует всем сообщениям с непустыми кладжами realname.
Полезно для модераторов, проверяющих, как подписчики себя обозначают.
код URLа: ...&find=/%5E\x1Category:\s.*(music%7cweather)/i выражение: /^\x1Category:\s.*(music|weather)/i найдёт кладж: Category: music найдёт кладж: Category: hardcore music найдёт кладж: Category: weather найдёт кладж: Category: real life, bad weather, bad mood
Соответствует всем сообщениям, которые принадлежат хотя бы к одной из заданных категорий.
Полезно для подбора сообщений на некоторую тему из блога или любого другого информационного канала с достаточно широким набором тем.
Однако снабжённая ярлыками эхопочта и фильтры "tag" (см. раздел 7.2.1.6) гораздо удобнее при составлении такой подборки, хотя регулярные выражения, возможно, более могучи.
Если есть нужда в том, чтоб некоторый URL содержал несколько регулярных выражений и означал фидонетовские сообщения, которые соответствуют хотя бы одному из этих регулярных выражений, тогда автору URLа НАДО объединить эти выражения в качестве альтернативных ветвей одного-единственного образца (выражение1|выражение2|...) -- как показано выше на примере, имеющем отношение к категориям.
Если есть нужда в том, чтоб некоторый URL содержал несколько регулярных выражений и означал фидонетовские сообщения, которые соответствуют каждому из этих регулярных выражений, тогда автору URLа НАДО использовать в этом URLе несколько параметров "find".
Так как это ТРЕБУЕТСЯ для вышеописанного поведения, типовое множество подытога фильтров "find" является пересечением фильтрованных множеств, определённых фильтрами "find".
Регулярное выражение 1: /^\x1Category:\s/i Регулярное выражение 2: /^\01Now\s+playing:\s/i
Найти сообщения, которые содержат оба кладжа "Category: " и "Now playing: " со следующим после двоеточия пробелом.
Простой текстовый поиск является менее жёстким, менее строгим, чем поиск по регулярному выражению. Поисковый движок МОЖЕТ искать не только по заданному слову, но также и по его морфологическим производным (например, "find=elf" МОЖЕТ соответствовать словам "elves", "elven", "elfin", "elfstone" и им подобным). Поисковый движок МОЖЕТ искать полное слово или интепретировать данный текст как фрагмент слова (например, "find=comp" МОЖЕТ соответствовать словам "overcomplicated" или "supercomputer", и им подобным). Направление и широта охвата при поиске обычно определяется настройками поискового движка или возможностями поискового движка.
Фильтр "subj" сходен с "find", единственное различие в том, что значение фильтра "subj" и заголовок сообщения ДОЛЖНЫ соответствовать (вместо тела сообщения, которое имело смысл для фильтра "find").
Фильтр "findsb" сходен с "find" или "subj", единственное различие в том, что значение фильтра "findsb" ДОЛЖНО соответствовать или телу сообщения, или строке темы сообщения, или обоим.
Примечание 1. Фильтр "findsb" не эквивалентен паре из "find" и "subj" с тем же значением: итоговое множество сообщений для различных фильтров ДОЛЖНО содержать только сообщения, принадлежащие к каждому из типовых множеств подытога, а вот фильтрованное множество "findsb" также содержит сообщения, в которых текст найден только в теме сообщения или только в теле сообщения.
Примечание 2. Фильтр "findsb", если он содержит только простой текст (не регулярное выражение), сходен с методом, которым работают интернетовские поисковые движки. И потому, если означенная область (означенные области) сообщений Фидонета не присутствуют локально в пользовательской базе сообщений, но есть соединение с Интернетом, тогда браузер Фидонета МОЖЕТ искать сообщения в Интернете, пользуясь интернетовской поисковой системою и эхогейтом. Например,
(последовательность символов "%%" используется здесь для обозначения того места, где разрыв строки появляется внутри URLа, а затем того места, где URL продолжается; см. подробнее в разделе 5.2.2.5).
Браузер Фидонета МОЖЕТ затем разобрать выходные данные интернетовской поисковой системы и выкачать текст желаемых сообщений.
Фильтр "to" сходен с "find", единственное различие в том, что значение фильтра "to" и имя адресата сообщения ДОЛЖНЫ соответствовать (вместо тела сообщения, которое имело смысл для фильтра "find").
Фильтр "sender" также сходен с "find", и единственное различие в том, что значение фильтра "sender" и имя отправителя сообщения ДОЛЖНЫ соответствовать (вместо тела сообщения, которое имело смысл для фильтра "find").
Примечания о безопасности: если вам нужно фильтрованное множество сообщений, которое содержит только сообщения от одного отправителя, тогда фильтр "sender" менее надёжен, чем фильтр "from". Среди людей есть тёзки и однофамильцы; а боты или UUE-кодеки всегда тёзки и однофамильцы, если запущены с одинаковыми настройками по умолчанию, даже когда они запущены нодами или пойнтами, имеющими различные адреса. Если отправителем является пользователь BBS, тогда вам НАДОБНО использовать как "from" для раздобывания сообщений от адреса той BBS, так и "sender", чтобы обеспечить имя получателя. Одновременно.
Сообщение эхопочты МОЖЕТ нести какую-либо пространственную ссылку на точку или область на земной поверхности. Источник сообщения (узел или пойнт Фидонета) также существует где-то на Земле. Оба эти факта МОГУТ использоваться, чтобы собрать сообщения эхопочты, относящиеся к некоторой области на земной поверхности, тем самым создавая из базы сообщений эхопочты пространственную базу данных ГИС.
7.2.1.5.1. Кладж GEO -+------------------
Кладжи (также известные под названием кладжевых строк или управляющих параграфов) -- это специальные строки, внедряемые в текстовое тело фидонетовского сообщения. Иногда кладжи обеспечивают поддержку новой адресации и другой управляющей информации, иногда они содержат элементы вспомогательных сведений об авторе сообщения (его местонахождение, номер ICQ, Jabber ID, реальное имя, играющая музыка, настроение, и т. п.). См. технические подробности в FTS-4000.
И чтобы поддержать новую адресацию (поддержать использование фильтров "geomark" в URLах FGHI, см. соответствующий раздел ниже), вводится новый кладж. Его строка имеет следующий формат:
<SOH>GEO: <Широта>;<Долгота>
Здесь <SOH> является одиночным символом SOH (Ctrl+A, ASCII 1).
Значение <Долгота> отображает положение к востоку или западу от нулевого меридиана в качестве положительного или отрицательного вещественного числа соответственно. Значения долготы в Фидонете ДОЛЖНЫ использовать гринвичский меридиан в качестве своего нулевого меридиана.
Значение <Широта> отображает положение к северу или к югу от экватора в качестве положительного или отрицательного вещественного числа соответственно.
Значения долготы и широты, если возможно, СЛЕДУЕТ указывать в соответствии с новой Мировой геодезической системою (WGS 84, см. на http://ru.wikipedia.org/wiki/WGS84 подробнее), которая является системою отсчёта в Глобальной системе позиционирования (GPS) и в Google Earth. (МОЖНО пользоваться и другими геоидами, если возможная разница в несколько сотен метров вас не беспокоит.)
Значения широты и долготы ДОЛЖНЫ быть указаны в десятичных градусах. Значения ДОЛЖНЫ разделяться символом точки с запятою (десятичный ASCII-код 59). Вот простая формула для преобразования градусов-минут-секунд в десятичные градусы:
десятичные = градусы + минуты/60 + секунды/3600.
Десятичная точка (символ ".") ДОЛЖНА использоваться для разделения целочисленной и дробной части десятичного числа, где и если есть нужда в такой пометке.
Пример:
^aGEO: 44.57;38.05
Здесь "^a" является одиночным символом SOH (Ctrl+A, ASCII 1).
Формат этого кладжа внутренне совместим с text/directory MIME-типом GEO (см. раздел 3.4.2 в RFC 2426) и микроформатом geo, как он на http://microformats.org/wiki/geo определён.
Этот кладж действительно удобен, к примеру, в сообщениях, содержащих фотографии (по кладжу на фотографию), поскольку затем фотографии из Фидонета МОГУТ быть расположены на карте или на глобусе подобно тому, как сайты http://panoramio.com/ и http://locr.com/ располагают их собственные базы данных с фотографиями.
Этот кладж удобен, к примеру, в сообщениях, которые содержат отчёты туристов о некоторых достопримечательных местах (по кладжу на место), если эти места достаточно малы для того, чтобы быть просто точками на карте. Чтобы ссылаться на географические области вместо точек, ДОЛЖЕН использоваться кладж "GEOBOX" (см. следующий подраздел).
Этот кладж НЕ СЛЕДУЕТ использовать для указания местонахождения отправителя сообщения, для которого СЛЕДУЕТ использовать или флаги в ноудлисте или пойнтлисте (см. раздел 7.2.1.5.4), или кладж ORIGEO (см. раздел 7.2.1.5.5). Пользователям Фидонета СЛЕДУЕТ воздержаться от использования кладжей GEO для пометки мест, не относящихся к содержанию сообщения.
7.2.1.5.2. Кладж GEOBOX -+---------------------
Этот кладж использует те же десятичные градусы, что и выше; однако он ссылается на регион на карте между двумя линиями долготы и двумя линиями широты, используя следующий формат:
<SOH>GEOBOX: <Запад>,<Юг>,<Восток>,<Север>
Здесь <SOH> является одиночным символом SOH (Ctrl+A, ASCII 1).
Значения <Запад> и <Восток> соответствуют ограничивающим линиям долготы; значения <Юг> и <Север> соответствуют ограничивающим линиям широты.
Указанный регион всегда прямоуголен в цилиндрической картографической проекции (например, на меркаторовской карте).
Пример:
^aGEOBOX: 37.98,44.54,38.13,44.61
Здесь "^a" является одиночным символом SOH (Ctrl+A, ASCII 1).
Формат этого кладжа внутренне совместим с тем форматом, который информация BBOX имеет по умолчанию в элементах <viewFormat> языка KML (смотрите в спецификации на http://code.google.com/apis/kml/documentation/kml_tags_21.html#link подробности), и с параметром BBOX для WMS, описанным в OGC 06-042 (OpenGIS Web Map Server Implementation Specification, version 1.3.0, 2006-03-15).
7.2.1.5.3. Кладж GEOKML -+---------------------
Этот кладж содержит одиночный URL некоторого KML- или KMZ-документа (объекта, файла); это может быть фидонетовский URL, но и интернетовский URL тоже может. С таким кладжем сообщение эхопочты обретает возможность сослаться на набор географических черт более сложных, нежели простые точки или прямоугольники, поскольку KML (или KMZ) способен содержать произвольные многоугольники, картографические покрытия, фотографические панорамы, трёхмерные объекты, развёрнутые во времени анимации, и так далее (см. на http://code.google.com/apis/kml/documentation/kml_tags_21.html подробнее).
Здесь "^a" является одиночным символом SOH (Ctrl+A, ASCII 1).
7.2.1.5.4. Координаты в ноудлистах и пойнтлистах -+----------------------------------------------
Сисопам и пойнтам Фидонета НЕ РЕКОМЕНДУЕТСЯ снабжать каждое сообщение своей собственной эхопочты кладжами GEO с обычным географическим местонахождением отправителя (в отличие от координат места, упомянутого или сфотографированного или как-то иначе относящегося к сообщению, содержащему эти координаты). Местонахождение отправителя (сисопа или пойнта Фидонета) СЛЕДУЕТ объявить лишь единожды, вывесив соответствующие пользовательские флаги в ноудлисте или пойнтлисте.
Такие флаги, если используются, ДОЛЖНЫ сообразовываться с разделом 6 ('Пользовательские флаги') FTS-5001; в частности, они МОГУТ содержать любые алфавитно-цифровые символы, кроме пробелов. Десятичная точка (символ "."), также считается алфавитно-цифровою, а двоеточие (символ ":") используется в качестве разделителя (см. на area://FTSC_Public/?msgid=2:280/5555+48c0e781 подробности).
Флаг LONE или LONW отображает положение к востоку или западу от нулевого меридиана соответственно. Значению долготы предшествует флаг, двоеточие разделяет их. Десятичная точка (символ ".") ДОЛЖНА использоваться для разделения целочисленной и дробной части десятичного числа, если дробная часть присутствует.
Пример:
LONE:38.5
(Этот флаг означает 38.05 градусов к востоку от нулевого меридиана.)
Флаг LATN или LATS отображает положение к северу или к югу от экватора соответственно. Значению широты предшествует флаг, двоеточие разделяет их. Десятичная точка (символ ".") ДОЛЖНА использоваться для разделения целочисленной и дробной части десятичного числа, если дробная часть присутствует.
Пример:
LATN:44.57
(Этот флаг означает 44.57 градусов к северу от экватора.)
Ограничения, перечисленные в разделе 7.2.1.5.1, все действуют: ДОЛЖЕН использоваться гринвичский меридиан, СЛЕДУЕТ использовать геоид WGS 84, НАДО использовать десятичные значения градусов.
Сисопам и сетевым координаторам СЛЕДУЕТ бережно избегать раздачи точных координат фидонетовских станций, в силу причиняемой ею значительной утраты уединения, секретности и личной жизни. Флагам СЛЕДУЕТ содержать уж лучше только координаты, которые соответствуют основному местному месту (городу, пригороду, и т. п.), объявленному в четвёртом поле той же строки (см. раздел 5.3 стандарта FTS-5000); двух цифр в дробной части значения (после подразумеваемой точки) должно хватить кому угодно. Это РЕКОМЕНДУЕТСЯ, если только у оператора узла или пойнта нету какой-либо причины помочь найти его (её) буквально кому угодно из читателей ноудлиста.
Заметьте, что ноудлистовые флаги, описанные в этом разделе, МОГУТ встретить (и встретят!) кое-какие помехи, поскольку, пока они не станут частью FTS-5001 и эпилога ноудлиста, они будут запрещены многими ZC и RC и NC и отвергаться многими программами проверки флагов ноудлиста. А FTSC, в свою очередь, склоняется к стандартизации только существующего обыкновения, которое никогда не соберётся расцвести, коли запрещается и отвергается. Однако сисопам и пойнтам Фидонета всё равно НЕ РЕКОМЕНДУЕТСЯ снабжать каждое сообщение своей собственной эхопочты кладжами GEO с обычным географическим местонахождением отправителя (в отличие от координат места, упомянутого или сфотографированного или как-то иначе относящегося к сообщению, содержащему эти координаты). Если отправителю не позволяется вывесить два нужных флага в ноудлисте (или пойнтлисте), ему (или ей) СЛЕДУЕТ использовать кладж ORIGEO, определённый в следующем подразделе.
7.2.1.5.5. Кладж ORIGEO -+---------------------
Кладж ORIGEO МОЖЕТ быть вставлен в фидонетовское сообщение и содержать местонахождение отправителя при одном или при нескольких из следующих обстоятельств:
*) Если вывешивание флагов, в которых указаны координаты, в ноудлисте или пойнтлисте (см. предыдующий подраздел) не дозволяется в соответствующем фидонетовском регионе (или зоне, или сети).
*) Если флаги в ноудлисте (или пойнтлисте) не содержат точных сведений о местонахождении отправителя сообщения (например, если они собираются стать точными только после следующего еженедельного обновления ноудлиста).
*) Если отправитель сообщения является фидонетовским пойнтом и не рассчитывает на то, что читатель (или читатели) сообщения будут знать о содержимом пойнтлиста босс-ноды, и в особенности о координатных флагах в его (её) пойнтовой строке. Или если его (или её) босс не дозволяет такие флаги в пойнтлисте босс-ноды.
*) Если отправитель сообщения не вблизи своего обычного местонахождения (например, в путешествии или в отпуске).
Отправителю сообщения СЛЕДУЕТ бережно избегать раздачи точных координат себя самого (себя самой), поскольку это может причинить значительную утрату уединения, секретности и личной жизни. Кладжу СЛЕДУЕТ содержать уж лучше только координаты, которые соответствуют основному местному месту (городу, пригороду, и т. п.). Если отправитель использует какое-либо устройство GPS и (или) ГЛОНАСС для получения своих координат со штатовских или русских космических спутников автоматически во время своего путешествия, тогда не более двух цифр в дробной части значения должно быть роздано. Это РЕКОМЕНДУЕТСЯ, если только у отправителя сообщения нету какой-либо причины помочь найти его (её) буквально кому угодно из читателей сообщения.
Синтаксис кладжа ORIGEO таков же, как у GEO:
<SOH>ORIGEO: <Широта>;<Долгота>
Здесь <SOH> является одиночным символом SOH (Ctrl+A, ASCII 1); значения широты и долготы ДОЛЖНЫ использовать тот же нулевой меридиан (гринвичский), и им СЛЕДУЕТ использовать тот же геоид (WGS84), что и в кладже GEO. Всё остальное в синтаксисе также то же самое, отличается только смысл: кладж GEO соответствуют содержимому сообщения, а кладж ORIGEO соответствует источнику сообщения.
7.2.1.5.6. Фильтры типа "geomark" -+-------------------------------
Значение фильтра "geomark" содержит четыре координатные ограничения в порядке <Запад>,<Юг>,<Восток>,<Север>, который совместим с тем же порядком, который информация BBOX по умолчанию имеет в элементах <viewFormat> языка KML (см. на http://code.google.com/apis/kml/documentation/kml_tags_21.html#link подробнее), и с параметром в BBOX для WMS, как он задан в OGC 06-042 (т. е. OpenGIS Web Map Server Implementation Specification, версии 1.3.0, 2006-03-15). Эти четыре координаты определяют регион на карте между двумя линиями долготы и двумя линиями широты.
Сообщение из первоначального множества сообщений появляется в фильтрованном множестве (определённом заданными координатами) в том и только в том случае, если как минимум одно (то есть одно или более) из нижеследующих требований выполняется:
1) Один (или более) из кладжей GEO в сообщении соответствует месту на Земле (точке на карте), которое принадлежит региону, заданному значением фильтра.
2) Один (или более) из кладжей GEOBOX в сообщении соответствует области на Земле (прямоугольнику на цилиндрической картографической проекции; например, на меркаторовской карте), которая пересекается с регионом, определённым значением фильтра.
3) Один (или более) из кладжей GEOKML в сообщении содержит URL, соответствующий KML- или KMZ-документу, который, в свою очередь, содержит один или более элемент (пометку места, многоугольник, путь, картографическое покрытие, фотографическую панораму, и т. п.), который принадлежит к региону, определённому значением фильтра, или пересекается с этим регионом.
Третье из этих условий терпит неудачу, если KML или KMZ не доступен немедленно (например, интернетовский URL на узле Фидонета, находящемся в оффлайне или вообще не соединённом с Интернетом, или фидонетовский URL, соответствующий ресурсу, преисполненному лага, типа faqserv:// или freq:// ко другому узлу, или типа area:// или fecho:// к области, на которую не оформлена подписка), и (или) если программа, разбирающая URL, недостаточно умна для анализа элементов KML с целью выборки их координат. Авторам эхопочты СЛЕДУЕТ подстраховывать их кладжи GEOKML при помощи добавления одного (или более) кладжей GEOBOX и (или) GEO с примерно подобной суммарной формою.
Если в необязательной части area-адреса присутствуют несколько фильтров "geomark", то типовое множество подытога фильтров "geomark" является объединением фильтрованных множеств, определённых фильтрами "geomark". (Например, если вы проверяете, принадлежит ли местоположение сообщения к некоторой фигуре сложной формы, то возможно аппроксимировать эту форму объединением нескольких внутренних областей "geomark".)
7.2.1.5.7. Фильтры типа "geofrom" -+-------------------------------
Значение фильтра "geofrom" содержит четыре координатные ограничения в порядке <Запад>,<Юг>,<Восток>,<Север>, который совместим с тем же порядком, который информация BBOX по умолчанию имеет в элементах <viewFormat> языка KML (см. на http://code.google.com/apis/kml/documentation/kml_tags_21.html#link подробнее), и с параметром в BBOX для WMS, как он задан в OGC 06-042 (т. е. OpenGIS Web Map Server Implementation Specification, версии 1.3.0, 2006-03-15). Эти четыре координаты определяют регион на карте между двумя линиями долготы и двумя линиями широты.
Сообщение из первоначального множества сообщений появляется в фильтрованном множестве (определённом заданными координатами) в том и только в том случае, если одно из нижеследующих требований выполняется:
1) Сообщение содержит кладж ORIGEO, который соответствует месту на Земле (точке на карте), которое принадлежит региону, заданному значением фильтра.
2) Сообщение не содержит кладжа ORIGEO, и сообщение происходит с адреса, соответствующего строке в ноудлисте или пойнтлисте, и координатные флаги этой строки (см. раздел 7.2.1.5.4) соответствуют месту на Земле (точке на карте), которое принадлежит региону, заданному значением фильтра.
3) Сообщение не содержит кладжа ORIGEO, и сообщение происходит с адреса, соответствующего строке в ноудлисте или пойнтлисте, и в строке нет координатных флагов (см. раздел 7.2.1.5.4), но основное местное место (город, пригород, и т. п.), объявленное в четвёртом поле той же строки (см. раздел 5.3 стандарта FTS-5000), принадлежит региону, заданному значением фильтра.
Третье из этих условий терпит неудачу, если обработчик URLов не способен на геокодирование (или местонахождение не известно обработчику). Сисопам и пойнтам Фидо НАДОБНО использовать координатные флаги (определённые в разделе 7.2.1.5.4) или кладжи ORIGEO (определённые в разделе 7.2.1.5.5), чтобы гарантировать корректную обработку своей эхопочты фильтрами типа "geofrom".
Если в необязательной части area-адреса присутствуют несколько фильтров "geofrom", то типовое множество подытога фильтров "geofrom" является объединением фильтрованных множеств, определённых фильтрами "geofrom". (Например, если вы проверяете, принадлежит ли местоположение отправителя к некоторой фигуре сложной формы, то возможно аппроксимировать эту форму объединением нескольких внутренних областей "geofrom".)
Иногда у читателя возникает нужда подобрать сообщения на одну некоторую тему из блога, или из новостного бюллетеня, или из любого другого информационного канала с достаточно широким набором тем.
Такая фильтрация легко реализуется при помощи эхопочты, снабжённой ярлыками, то есть когда каждое из (или большинство) эхопочтовых сообщений содержит одну или несколько кратких текстовых пометок (ярлыков).
Подробности объярлычивания и фильтрации, для того нужных, даны в следующих подразделах.
7.2.1.6.1. Кладж TAG -+------------------
Кладжи (также известные под названием кладжевых строк или управляющих параграфов) -- это специальные строки, внедряемые в текстовое тело фидонетовского сообщения. Иногда кладжи обеспечивают поддержку новой адресации и другой управляющей информации, иногда они содержат элементы вспомогательных сведений об авторе сообщения (его местонахождение, номер ICQ, Jabber ID, реальное имя, играющая музыка, настроение, и т. п.). См. технические подробности в FTS-4000.
И чтобы поддержать новую адресацию (поддержать использование фильтров "tag" в URLах FGHI, см. соответствующий раздел ниже), вводится новый кладж. Его строка имеет следующий формат:
<SOH>TAG: <список ярлыков>
Здесь <SOH> является одиночным символом SOH (Ctrl+A, ASCII 1).
Значение <список ярлыков> содержит список ярлыков, разделённых символом "|".
Пример:
<SOH>TAG: SimpleX|new version|announcement
(Этот пример содержит три ярлыка: "SimpleX", "new version", и "announcement".)
Сообщение эхопочты может содержать несколько кладжей TAG.
Пример:
<SOH>TAG: this is the first tag, it spans the whole line <SOH>TAG: this is the second tag|this is the third tag
В целях интернационализации, кладжи TAG (и содержащиеся в кладжах TAG ярлыки) ДОЛЖНЫ рассматриваться в соответствии с тем же набором символов (кодовой страницею), что и тело сообщения, см. подробности в FSC-0054 и FSP-1013.
Кладжи TAG (и содержащиеся в кладжах TAG ярлыки) МОГУТ также содержать символы, не присутствующие в наборе символов (кодовой странице) их эхопочтового сообщения. Такие символы ДОЛЖНЫ даваться как десятичные ссылки на символы в соответствии с разделом 3.2.3 HTML 4.01: http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.3
Вкратце говоря, каждый такой символ ДОЛЖЕН быть представлен своим десятичным номером Unicode, которому непосредственно предшествует последовательность "&#", и за которым непосредственно следует точка с запятою (символ ";").
Пример:
<SOH>TAG: вѣсть
Амперсанд (символ "&") является особенным и ДОЛЖЕН быть представлен символьной последовательностью "&" или "&".
Символ "|" также является особенным: если ярлык содержит его, то (чтобы не быть принятым за разделитель между ярлыками) этот символ ДОЛЖЕН быть удвоен.
Пример:
<SOH>TAG: more sort&more examples as "sort||more"
Ярлык, использованный в этом примере:
more sort&more examples as "sort|more"
7.2.1.6.2. Фильтры типа "tag" -+---------------------------
Значение фильтра "tag" содержит ярлык или несколько ярлыков, разделённых символом "|". (Символ "|" считается особенным: если ярлык содержит его, тогда, чтобы не быть принятым за разделитель между ярлыками, символ этот ДОЛЖЕН быть удвоен.)
(Здесь последовательность "%7C" представляет символ "|", который небезопасен, см. раздел 5.2.2.2.)
Сообщение из первоначального множества сообщений появляется в фильтрованном множестве (определённом заданным ярлыком или ярлыками) в том и только в том случае, если как минимум один (то есть один или более) из ярлыков сообщения в точности дан в значении фильтра.
Примеры:
URL: ...&tag=hot%7Cpretty%7Chardcore значение фильтра: hot|pretty|hardcore соответствует TAGу: top|hot|bot не соответствует TAGу: bad mood|hot weather
(Соответствие должно быть точным, а не подстрокою.)
URL: ...&tag=%D0%B2%D1%A3%D1%81%D1%82%D1%8C соответствует TAGу: вѣсть
Октеты UTF-8 в URLе (см. раздел 5.2.1) соответствуют десятичным ссылкам на символы в ярлыке (см. раздел 7.2.1.6.1).
Если в необязательной части area-адреса присутствуют несколько фильтров "tag", то типовое множество подытога фильтров "tag" является пересечением фильтрованных множеств, определённых фильтрами "tag".
Пример:
URL: ...&tag=software&tag=announcement соответствует: SimpleX|software|announcement|changelog не соответствует: HellEd|software|feature request
Обратите внимание, что нет никакой разницы, объединены ли ярлыки эхопочты в одном кладже TAG или располагаются каждый в своём кладже TAG. К примеру, если сообщение эхопочты имеет четыре кладжевые строки с нижеследующим содержимым:
тогда сообщение также соответствует обоим фильтрам из предыдущего примера ("tag=announcement" и "tag=software").
7.2.1.7. Фильтры типа "ttop" -+--------------------------
Если один или более фильтров "ttop" присутствует в URLе, то фильтрованное множество сообщения для каждого из этих фильтров (и, следовательно, для всех их совокупно) содержит только те сообщения, которые не являются ответами ни на одно сообщение из той же эхопочтовой области.
Сообщение из первоначального множества сообщений появляется в фильтрованном множестве в том и только том случае, когда соблюдается одно из следующих требований:
1) Сообщение не содержит кладжа REPLY.
2) Сообщение содержит некоторый кладж REPLY, но значение этого кладжа не соответствует кладжу MSGID ни одного другого сообщения той же эхопочтовой области.
Значение этого фильтра ДОЛЖНО быть проигнорировано; одним лишь наличием или отсутствием его определяется поведение браузера. РЕКОМЕНДУЕТСЯ указать пустое значение и не использовать символ "=", тем самым удерживая длину URLов "area://..." в разумных пределах.
Применяя фильтр "ttop" в URLе, когда в том есть нужда, автор URLа способен достигнуть блогосферического режима выборки сообщений, когда только свойства блогозаписей (то есть начальных сообщений в обсуждениях) имеют значение, а ответы на эти записи не имеют значения.
Аналогии в доFGHIном мире:
*) В календаре LiveJournal только блогозаписи выбираются в соответствии с заданным годом и месяцем (дата и время откликов не имеют значения, и заданный год и месяц не используются для выборки и показа отдельных откликов):
*) RSS-потоки, экспортируемые из большинства современных блогов, низкопробны в сравнении с нашими фидонетовскими потоками эхопочты: такие RSS-потоки однонаправлены и содержат только блогозаписи, в то время как фидонетовская эхопочта двунаправлена и содержит все сообщения (не только начинающие тему). Например, LiveInternetовское сообщество девственниц:
Если этот поток синдицируется и появляется на некотором другом блогохостинге (таком, как LiveJournal), ни один из комментариев с этого хостинга не вещается назад к источнику записей:
Хотя двунаправленная природа фидонетовской эхопочты всегда является достоинством, отдельных читателей Фидонета МОГУТ всё равно интересовать не комментарии, а только те записи, которые начинают новые темы, новые нити эхопочтового обсуждения (например, если эхопочтовая область вещает новости, или если это блогоэха, то некоторые читатели МОГУТ пожелать читать только первоначальные сообщения автора блога или новостного робота, а не последующие обсуждения).
В догипертекстовом Фидонете для такого разделения записей и комментариев ТРЕБОВАЛИСЬ некоторые дополнительные действия на уровне управления эхопочтою (всегда создавая раздельные две области эхопочты вместо всего одной, такие как CU.Price и CU.Price.Talk, $Crack$ и $Crack$.Talks, Ru.San_Izone и Ru.San_Izone.Talks, 1072.CompNews и 1072.CompNews.Talk, Ru.BBSNews и Ru.BBSNews.Talk, Ru.FastUUE и Ru.FastUUE.Talk, и т. д.), а ещё ТРЕБОВАЛИСЬ беспрерывные усилия модераторов (т. е. комментарии в неразговорных областях приходилося запрещать, и комментаторов наказывать и принуждать отвечать в соответствующей разговорной области). В гипертекстовом Фидонете такое разделение становится индивидуальным: каждому читателю НАДОБНО быть в состоянии приказать своему браузеру о добавлении фильтра "ttop" к URLу (и о обновлении вида), НАДОБНО быть в состоянии поделиться итоговым URLом с другими читателями, коль возникнет в том нужда.
Примечание 1: если читателю есть нужда быть осведомлённым обо всех недавних широковещательных сообщениях вместо только тех сообщений, которые начали новые нити обсуждения, тогда фильтр "to=All" НАДОБНО использовать вместо фильтра "ttop", поскольку сообщения, адресованные всем подписчикам, МОГУТ появляться как отклики на некоторые другие сообщения в той же эхопочтовой области. Если читателю некоторой блогоэхи есть нужда быть осведомлённым только о сообщениях автора эхи, тогда фильтр "ttop" НАДОБНО использовать в совокупности с фильтром "from" (со значением фильтра "from", равным фидонетовскому адресу автора блога), поскольку время от времени и комментаторы блога МОГУТ начинать нити. (То же справедливо и для эхопочтовых областей новостей, где робот, помещающий новости, является своего рода автором блога.)
Примечание 2: когда интернетовский форум показывает нити, в которых есть недавние отклики (например, "Order: Last Post" в конце http://forum.emule-project.net/index.php?showforum=5 и других сайтов на основе IPB), то ясно, что некоторая хронологическая выборка применяется ко всем сообщениям нитей. Даже если показываются лишь немного строчек для каждой нити, или показывается только сообщение, начавшее эту нить, то это не вопрос выборки сообщений, это вопрос вида. То же различие существует и в URLах Фидонета: автор URLа использует фильтр "ttop", когда есть нужда применять остальные фильтры только к начальным сообщениям нитей; но если фильтры НУЖНО применять к целым нитям, хотя только начальные сообщения нитей СЛЕДУЕТ показать, то автору URLа НУЖНО воздержаться от использования фильтра "ttop", а СЛЕДУЕТ использовать необязательный параметр "view" (см. раздел 7.2.3): например, "view=topl+totr".
Будущие версии этого документа могут вводить дополнительные фильтры сообщений. Скажем, гипертекстовые сообщения могут фильтроваться на основе метаинформации из их HTML-заголовка. Также сообщения могут быть найдены при помощи методов других, нежели регулярные выражения.
Однако отбрасывание неизвестных необязательных параметров area-адреса является безопасным, хотя воспринимающим фидонетовские URLы программам СЛЕДУЕТ, возможно, предупреждать своих пользователей, если неизвестный параметр отбрасывается и когда такое предупреждение уместно.
7.2.2. Закодированные объекты внутри эхопочтовых сообщений -+--------------------------------------------------------
Фидонетовское эхопочтовое сообщение может содержать один или несколько двоичных объектов, закодированных для того, чтобы иметь вид текстоподобных строк символов. Среди возможных методов такого кодирования можно назвать UUE, MIME (RFC 2045-2049), "data:" (RFC 2397), и т. п.
Эхопочтовое сообщение МОЖЕТ содержать несколько объектов, и они МОГУТ быть закодированы разными способами. С другой стороны, закодированный объект МОЖЕТ располагаться в нескольких фидонетовских сообщениях: например, каждое из этих фидонетовских сообщений МОЖЕТ нести одну или две UUE-секции, и весь набор секций потребуется при декодировании файла.
7.2.2.1. Имена кодированных объектов -+----------------------------------
Этот подраздел приводится для сведения.
Большинство объектов, закодированных внутри эхопочтовых сообщений, имеют имя.
Имя UUE-закодированного объекта обычно появляется в строке "begin" и (или) "section" UUE-кодов.
Имя MIME-кодированного объекта обычно появляется либо внутри заголовка "Content-type" (в разделе "name" этого заголовка), либо внутри заголовка "Content-disposition" (в разделе "filename" этого заголовка).
RFC 2397 "data:" не указывает имя объекта; однако тот объект гипертекста, которому соответствуют данные, МОЖЕТ сам быть поименован при посредстве атрибута "id" или "name" в его тэге.
7.2.2.2. Как определяется означенный объект -+-----------------------------------------
Если <путь-объекта> в area-адресе не пуст, то его URLом оказывается означен либо закодированный объект в целом, либо некоторая внутренняя часть такого объекта. Отвлекаясь от этих внутренних деталей, назовём целый объект "означенным объектом" в этом подразделе.
Если <путь-объекта> в area-адресе не пуст, то и <имя-объекта> ДОЛЖНО также быть непустым по определению, и в нём указано имя означенного объекта.
Однако в эхопочтовой базе сообщений (базе тех областей, которые названы в разделе <areatag> заданного URLа) МОЖЕТ иметься больше одного объекта под одним и тем же именем. И потому важно определить, какой объект считается "последним".
Среди тех сообщений, в которых содержатся одноимённые объекты (или только части таких объектов -- скажем, UUE-секции), есть последнее сообщение. Если это последнее сообщение содержит только один из этих объектов (частично или полностью), тогда этот объект является последним. Если это последнее сообщение содержит части и (или) целые закодированные образы более чем одного объекта с одним и тем же именем, тогда тот объект, чей закодированный образ или лишь последняя секция такового (последняя из секций, присутствующих в последнем сообщении) появляется ближайшей к концу этого сообщения (наиболее далёкой от его начала), является последним объектом.
Определение самого "последнего сообщения" не входит в задачи данного документа. Им МОЖЕТ быть последнее принятое сообщение, им МОЖЕТ быть сообщение с наибольшей датой создания, и т. п.
Означенный объект всегда определяется как последний среди тех, чьё имя указано в <имя-объекта>.
Фидонетовский браузер ДОЛЖЕН игнорировать объекты, закодированные таким способом, который непонятен браузеру; означенный объект ДОЛЖЕН всегда быть последним среди только тех объектов с заданным именем, которые возможно декодировать из базы сообщений эхопочты.
Если в необязательной части URLа есть один или несколько фильтров сообщений, тогда означенный объект является последним среди только тех способных быть декодированными одноимённых объектов, чей закодированный образ (или хотя бы одна секция кода) имеется в том сообщении или среди тех нескольких сообщений, которые принадлежат к итоговому подмножеству полной базы сообщений; а какие сообщения появятся в том итоговом множестве сообщений, определяется налагаемыми фильтрами.
Если означенный объект может быть декодирован, но содержит неизвестный контейнер (то есть контейнер, который не может быть открыт фидонетовским браузером), тогда такой объект НЕ ДОЛЖЕН быть проигнорирован безусловно (то есть как если бы он не мог быть декодирован); браузер ДОЛЖЕН сообразовываться с правилами обработки неизвестных контейнеров (см. раздел 7.1.2).
Так как <имя-объекта> всегда относится к последнему среди одноимённых объектов, то URL "area://" может означать объект, обновляемый при посредстве фидонетовской эхопочты. Такие объекты могут обновляться ежедневно (как в прогнозе погоды), еженедельно (как в статистическом отчёте насчёт ноудлиста), и так далее. Вот каким способом Фидонет может предоставлять динамический свежий контент. А если некий URL должен указывать на некую прежнюю статическую версию вместо наисвежайшей динамической, тогда фильтр сообщений (если он соответствует одному лишь сообщению или достаточно узкому подмножеству сообщений) всегда сможет это обеспечить. Например, фильтр "msgid" и (или) "time".
Если несколько узлов имеют доступ на запись к одной и той же эхе, и невозможно полагаться просто на последний одноимённый объект, тогда можно использовать фильтр "from", обеспечив выбор доверенного источника.
Так как всякий фидонетовский браузер ДОЛЖЕН игнорировать объекты, способ кодирования которых ему не понятен, то возможным является включение нескольких альтернативных версий одного и того же объекта (по-разному закодированных), даже в одном и том же письме эхопочты, при том условии, что имена опубликованных версий объекта одинаковы. И браузер счастливо подберёт тот способ кодирования, который он сможет понять. К примеру, кто-нибудь может одновременно публиковать как UUE (для GoldEd+), так и RFC 2397 (для Gecko) версии одного и того же значка.
Примеры:
1) Информеры погоды в Интернет всегда имеют один и тот же URL, но их изображения регулярно обновляют, чтобы показывать погоду на завтра.
Чтобы достигнуть в Фидонете того же результата, робот МОЖЕТ отправлять UUE-кодированные изображения, содержащие прогнозы погоды (всегда под одним и тем же именем файла) в некоторую область эхопочты (дважды в день, или трижды, или четырежды). URL информера, таким образом, МОЖЕТ иметь следующую форму:
2) Эхопочтовая область в Фидонете МОЖЕТ быть аналогична интернетовскому имиджборду, или чэну (см. в статье Википедии http://tinyurl.com/6ne3ty подробности). Если все изображения в такой картиночной эхе имют одно и то же имя файла, они всё ещё МОГУТ быть адресованы по MSGIDам:
Однако area://Example.Imageboard/image всегда является последней картинкою, опубликованною на означенном имиджборде Фидонета. Кто угодно, подписанный на эту область, МОЖЕТ использовать этот URL как источник своих обоев и медитировать, в то время как картинка изменяется после каждого тоссинга входящей эхопочты Фидонета.
3) У расширенного XML-эхолиста или у BBS в Паутине часто возникает нужда иметь URLы последних правил для всех областей эхопочты. Всякий модератор МОЖЕТ давать одно и то же имя файла всякий раз тексту правил его (или её) области, когда текст этот отсылается; имя файла МОЖЕТ быть указано, к примеру, с использованием (de facto) стандарта текстовых секций (определённого Сергеем Коровкиным в 1998 году, поддерживаемого UUE Wizard, FastPost, FastUUE и некоторым другим программным обеспечением); например, тексту правил МОГУТ всегда предшествовать две строки
textsection 1 of 1 of file rules.txt textbegin.all
а за ним следовать строка
textend.all
и, таким образом, постоянный URL для правил этой эхи будет
(здесь 1:23/45.6 стоит в качестве примера, и его НАДО в реальной жизни заменять реальным адресом модератора). URL работал бы даже после того, как модератор обновит правила области на некоторую новую версию.
На любую конкретную версию правил также МОЖНО сослаться добавлением фильтра по времени к вышеприведённому URLу; например,
означает последние правила, опубликованные в июле 2008 г.
7.2.3. Вид представления сообщений -+--------------------------------
Когда итоговое множество сообщений уж определено, ещё остаётся несколько способов отобразить его. В некоем окне фидонетовского браузера сообщения МОГУТ образовать или дерево, или список, или своего рода телетайпную ленту (ленту конвейера, рулон, свиток), или даже появляться одно за одним, по сообщению за раз, с некими средствами для их перелистывания.
Обыкновенно одни только настройки, установленные пользователем браузера, определяют вид, который выбирается браузером Фидонета. Однако, в некоторых обстоятельствах, автор URLа МОЖЕТ пожелать предложить один или более видов, которые он (или она) почитают нужными. В таком случае автору URLа не ТРЕБУЕТСЯ составлять нужную часть URLа вручную; браузер МОЖЕТ помочь. Например, МОГУТ быть два режима: по умолчанию, когда пользователь меняет вид, браузер Фидонета запоминает вид только внутренне; в специальном режиме браузер Фидонета также переменяет URL на панели адреса, откуда пользователь может взять такой URL, в котором отразился желаемый вид.
Значение необязательного параметра "view" содержит либо один жетон вида, либо список разделённых пробелом жетонов вида.
Каждый из жетонов вида является коротким словом или сокращением (не чувствительным к регистру), которое соответствует предлагаемому виду. Длина жетона всегда равна четырём символам. Вот все возможные жетоны, в алфавитном порядке:
*) bran (его определение дано в разделе 7.2.3.5) *) cale (его определение дано в разделе 7.2.3.14) *) elst (его определение дано в разделе 7.2.3.20) *) exbr (его определение дано в разделе 7.2.3.11) *) expa (его определение дано в разделе 7.2.3.10) *) flat (его определение дано в разделе 7.2.3.12) *) flbr (его определение дано в разделе 7.2.3.13) *) glom (его определение дано в разделе 7.2.3.17) *) list (его определение дано в разделе 7.2.3.3) *) litr (его определение дано в разделе 7.2.3.6) *) mapm (его определение дано в разделе 7.2.3.15) *) objs (его определение дано в разделе 7.2.3.19) *) reel (его определение дано в разделе 7.2.3.7) *) sglo (его определение дано в разделе 7.2.3.18) *) sing (его определение дано в разделе 7.2.3.2) *) smap (его определение дано в разделе 7.2.3.16) *) topl (его определение дано в разделе 7.2.3.9) *) totr (его определение дано в разделе 7.2.3.8) *) tree (его определение дано в разделе 7.2.3.4)
Фидонетовский браузер МОЖЕТ полностью проигнорировать параметр "view", согласно пользовательским настройкам браузера или настройкам по умолчанию. Если браузер решает учесть параметр, тогда браузеру СЛЕДУЕТ взять первый данный жетон и отобразить предлагаемый жетоном вид. Если браузер не способен отобразить предложенный вид (не предполагается, что все фидонетовские браузеры способны отображать все возможные виды, перечисленные в следующих подразделах этого раздела), тогда браузеру СЛЕДУЕТ взять следующий жетон и выяснить, способен ли он отобразить вид, который этот жетон предлагает, и так далее. (И если в итоге ни один из жетонов не предлагает вид, который браузер способен отобразить, тогда параметр "view" ДОЛЖЕН наконец быть проигнорирован.)
Например, если браузеру встречается следующий URL:
(где знаками "+" представлены пробелы, см. раздел 5.2.2.4) и в браузере не реализован вид списка (который соответствует жетону "list"), но в браузере реализован вид дерева (который соответствует жетону "tree"), тогда браузеру СЛЕДУЕТ отобразить область FTSC_Public в виде дерева (если только установки браузера не велят проигнорировать параметр "view" совсем).
Если в URLе несколько параметров "view", и если браузер не собирается их игнорировать, тогда каждый из параметров ДОЛЖЕН быть проанализирован, чтоб найти первое из тех предложений, которые действительно МОГУТ быть отображены браузером. Если такое реалистическое предложение является одним и тем же для каждого из параметров, тогда это и есть то предложение, коему браузеру НАДОБНО последовать. Если же дано несколько различных реалистических предложений, тогда браузер МОЖЕТ дать выбрать пользователю, или МОЖЕТ последовать каким-либо предпочтениям, установленным в его настройках.
Автору URLа не ТРЕБУЕТСЯ заучивать все жетоны; ему (или ей) НАДОБНО быть способным скопировать URL с адресной панели браузера (или с любого другого в равной степени удобного элемента интерфейса браузера), и поэтому СЛЕДУЕТ обеспечить настройку, чтобы выбирать, отображаются ли пользовательские изменения вида на адресной панели (в параметре "view=..." URLа) или просто внутренне принимаются во внимание браузером (так что URL на адресной панели не содержит параметра "view=...", если считается, что нет в нём нужды).
7.2.3.2. Вид единственного сообщения -+----------------------------------
Жетоном для этого вида является "sing" (нечувствительным к регистру, и без кавычек).
В этом режиме просмотра читатель видит сообщения эхопочты только по одному. Ему (или ей) обыкновенно обеспечиваются какие-либо средства навигации к следующему или предыдущему сообщению в той же эхопочтовой области.
Аналогии в доFGHIном мире:
*) Это режим просмотра, используемый в GoldEd+ при чтении фидонетовских сообщений. Если настройка "MsgListFirst No" присутствует в конфигурационном файле GoldEd+, тогда это также режим просмотра по умолчанию при входе GoldEd+ в эхопочтовую область.
Этот вид бывает одним из наиболее уместных, если итоговое множество сообщений (определённое фильтрами) содержит в себе только одно сообщение. Если итоговое множество сообщений содержит несколько сообщений, тогда ДОЛЖЕН быть какой-нибудь интерфейс для перепрыгивания между сообщениями итогового множества, в дополнение к обычным средствам пролистывания сообщений эхопочтовой области. (Если только итоговое множество сообщений уже не является эхопочтовой областью, например когда в URLе упомянута только одна область, а фильтров нет или все сообщения удовлетворяют фильтрам.)
Если URL повелевает использовать вид единственного сообщения, тогда фильтры МОГУТ применяться с некоторой экономией времени и усилий, только до тех пор пока первое сообщение итогового множества не будет найдено и отображено, так что следующее сообщение итогового множества отыскивается, только если пользователь перепрыгивает к нему. Например, если применение поискового фильтра стоит значительного количества времени, то браузер МОЖЕТ найти и отобразить первое найденное сообщение, и остановить поиск до тех пор, пока кнопка "Предыдущее сообщение" или "Следующее сообщение" не будет нажата (и она тогда подействует как "Найти предыдущее" или "Найти следующее" соответственно). Конечно, это просто грубый пример; некоторые браузеры МОГУТ также выполнить ещё один шаг такой фильтрации загодя, чтоб выяснить, активна ли кнопка "Следующее сообщение" (или "Предыдущее сообщение"), и чтоб быть способными прыгнуть без промедления, а поиск выполнять в фоне загодя.
Порядок сортировки (см. раздел 7.2.6) определяет, какое сообщение является первым и какие следующими.
7.2.3.3. Список сообщений -+-----------------------
Жетоном для этого вида является "list" (нечувствительным к регистру, и без кавычек).
В этом режиме просмотра читатель видит отсортированный список сообщений, представленных только их строками заглавий и, возможно, некоторой другой информацией из их заголовка (их дата и время, их отправитель и адресат), но не телами сообщений.
В зависимости от конструкции и настроек браузера, читателю обычно даются какие-либо средства для выбора и просмотра любого из перечисленных сообщений; например, он (или она) МОЖЕТ быть способна войти в режим единственного сообщения (описанный в предыдущем разделе), чтобы увидеть выбранное сообщение; или, например, МОЖЕТ появиться дочернее окно под списком и отобразить выбранное сообщение.
Аналогии в доFGHIном мире:
*) Это режим просмотра, используемый в GoldEd+ при чтении фидонетовских областей сообщений. Если настройка "MsgListFirst Yes" присутствует в конфигурационном файле GoldEd+, тогда это также режим просмотра по умолчанию при входе GoldEd+ в эхопочтовую область.
*) Это режим просмотра, используемый в LiveJournal при просматривании эхопочтовых сообщений, транслируемых из RSS-потока. Например, см. блогосферическое зеркало области Ru.FTN.Develop: http://syndicated.livejournal.com/ruftndevelop/
Списку сообщений НАДОБНО содержать только итоговое множество сообщений согласно фильтрам сообщений. В зависимости от конструкции и настроек браузера, список сообщений МОЖЕТ содержать некоторые другие сообщения (например, если итоговое множество сообщений является подмножеством некоторой области эхопочты, тогда другие сообщения этой области МОГУТ появиться в списке), но в этом случае читатель ДОЛЖЕН быть способен различить сообщения из итогового множества: они ДОЛЖНЫ оказаться подсвеченными, и (или) другие сообщения ДОЛЖНЫ оказаться посеревшими, и т. п.
Порядком сортировки (см. раздел 7.2.6) определяется порядок сообщений в списке.
7.2.3.4. Дерево ответов -+---------------------
Жетоном для этого вида является "tree" (нечувствительным к регистру, и без кавычек).
Этот режим просмотра представляет (изображает) полное дерево ответов в некотором эхопочтовом обсуждении. Дерево начинается изначальным сообщением; первый ответ на него (как определяется кладжем REPLY, см. FTS-0009) появляется с отступом ниже изначального сообщения, а первый ответ на этот ответ появляется нижу с ещё большим отступом, и так далее. Следующие ответы появляются на том же уровне отступа, что и их собратья (то есть ответы на одно и то же сообщения появляются на одном и том же уровне отступа). И наконец образуется древоподобная структура ветвей и листьев, как в следующем примере:
Изначальное сообщение Ответ A на изначальное сообщение Ответ 1 на сообщение A Ответ 2 на сообщение A Ответ 3 на сообщение A Ответ B на изначальное сообщение Ответ C на изначальное сообщение Ответ 1 на сообщение C Ответ 2 на сообщение C Ответ 2a на вышележащий второй ответ Ответ 2b на вышележащий второй ответ Ответ 3 на сообщение C Ответ 4 на сообщение C Ответ D на изначальное сообщение Ответ E на изначальное сообщение
Где-то среди этих сообщений и ответов есть сообщение из итогового множества сообщений (составленного согласно фильтрам сообщений). Это сообщение ДОЛЖНО быть подсвечено; и если какие-либо другие сообщения из того же дерева ответов принадлежат к итоговому множеству сообщений, им СЛЕДУЕТ также быть несколько подсвеченными.
Если итоговое множество сообщений состоит более чем из одного сообщения, тогда читателя НАДО снабдить какими-либо средствами для перепрыгивания между такими сообщениями. (И если следующее или предыдущее сообщение итогового множества, которое достигнуто таким прыжком, принадлежит к другому дереву ответов, тогда это новое дерево НАДО составить и показать после прыжка; и если дерево достаточно велико, так что оно не помещается на экране, и оттого появляется некоторая прокрутка, то дерево НАДОБНО прокрутить так, чтоб читатель видел подсвеченное сообщение, место назначения прыжка.)
Порядок сортировки сообщений (см. раздел 7.2.6) определяет порядок тех ветвей, которые принадлежат к одному уровню дерева; например, который из ответов A, B, C, D, E (и соответствующих им ветвей под ними) показывается первым. Порядок сортировки сообщений также определяет порядок сообщений в итоговом множестве сообщений (то есть он таков же, как и порядок, проявляющий себя в последовательности последовательных перепрыгиваний).
Сообщения в этом режиме просмотра представлены только некоторыми элементами их заголовка; ими МОГУТ быть их строки заглавия, и (или) их дата и время, и (или) их отправитель, и (или) их адресат, но не тела сообщений.
В зависимости от конструкции и настроек браузера, читателю обычно даются какие-либо средства для выбора и просмотра тела любого из сообщений дерева; например, он (или она) МОЖЕТ быть способна войти в режим единственного сообщения (описанный в разделе 7.2.3.2), чтобы увидеть выбранное сообщение; или, например, МОЖЕТ появиться дочернее окно под деревом и отобразить выбранное сообщение. Читателю МОЖЕТ также быть дан какой-либо переключатель для раскрытия и сокрытия сообщения внутри дерева (под заголовком сообщения); читателю МОГУТ быть даны какие-либо средства для раскрытия и сокрытия целых ветвей дерева.
Аналогия в доFGHIном мире:
*) Дерево ответов реализовано в GoldEd+ и переключается командою READthreadtree (которая обыкновенно назначается на клавишу F8).
7.2.3.5. Ветвь ответов -+--------------------
Жетоном для этого вида является "bran" (нечувствительным к регистру, и без кавычек).
Этот режим просмотра подобен дереву ответов (см. предыдущий раздел), со следующими отличиями:
1) Прежде построения вида, первое из сообщений (согласно порядку сортировки сообщений, см. раздел 7.2.6) отыскивается в итоговом множестве сообщений (которое определено фильтрами сообщений). Вместо полного дерева отображается только ветвь, начинающаяся от этого первого сообщения. Первое сообщение итогового множества становится корнем этой ветви.
2) Всякий раз, когда читатель перепрыгивает к любому другому сообщению из итогового множества сообщений, отображается новая ветвь ответов, начинающаяся с этого сообщения как от нового корня ветви.
3) Корневое сообщение ветви (т. е. первое сообщение итогового множества, или, после перепрыгивания, любое из следующих сообщений итогового множества) отображается целиком (т. е. заголовок и тело сообщения), в то время как ответы на него (и ответы на эти ответы, и так далее) по-прежнему показываются компактными (то есть представленными только некоторыми элементами их заголовка).
4) Читателю МОЖЕТ быть дана гиперссылка (или любой другой элемент интерфейса), которая может быть использована для перехода на один уровень выше от корня ветви, если он не является корнем дерева.
Жетоном для этого вида является "litr" (нечувствительным к регистру, и без кавычек).
Этот режим просмотра подобен дереву ответов (см. раздел 7.2.3.4), но несколько деревьев отображаются на одном и том же экране (на одной и той же странице, в одном и том же окне, и т. д.): все деревья, которые содержат сообщения из итогового множества сообщений (которое определено присутствующими в URLе фильтрами сообщений). В зависимости от конструкции и настроек браузера, список деревьев МОЖЕТ содержать некоторые другие деревья (например, если итоговое множество сообщений является подмножеством некоторой области эхопочты, тогда другие деревья этой области МОГУТ появиться в списке), но в этом случае читатель ДОЛЖЕН быть способен различить сообщения из итогового множества: они ДОЛЖНЫ оказаться подсвеченными, и (или) другие сообщения ДОЛЖНЫ оказаться посеревшими, и т. п.; в этом случае читателю СЛЕДУЕТ также быть способным различить (с одного взгляда), содержит ли некоторое дерево хотя бы одно из сообщений из итогового множества сообщений (следовательно, НАДОБНО переменить кое-какие цвета тех деревьев, которые не содержат никаких сообщений итогового множества сообщений, или другими средствами сделать их заметными для читателя).
Таким образом, если читатель перепрыгивает к предыдущему или последующему сообщению из итогового множества сообщений, тогда список деревьев остаётся тем же; только фокус читательского внимания переменяется, поэтому браузеру СЛЕДУЕТ переменить подсветку и прокрутить страницу, где и если есть в том нужда.
Порядок сортировки сообщений (см. раздел 7.2.6) определяет порядок деревьев, и порядок ветвей на каждом уровне дерева, и последовательность перепрыгивания между сообщениями, принадлежащими итоговому множеству сообщений.
Аналогия в доFGHIном мире:
*) Посетите Keyhole BBS (форум сообщества Google Earth):
Нечётные деревья на белом фоне; чётные деревья светло-серые.
7.2.3.7. Лента сообщений -+----------------------
Жетоном для этого вида является "reel" (нечувствительным к регистру, и без кавычек).
В этом режиме просмотра сообщения целиком (заголовки сообщений и соответствующие тела сообщений) из итогового множества сообщений появляются одно под другим, образовывая одну более или менее длинную страницу. Порядок ответов не принимается по внимание; только порядок сортировки сообщений (см. раздел 7.2.6) определяет, какое сообщение первое, какое следующее, и так далее.
(Последовательность символов "%%" используется здесь для обозначения того места, где разрыв строки появляется внутри URLа, а затем того места, где URL продолжается; см. подробнее в разделе 5.2.2.5. Также отметьте, что RSS-поток, предоставленный Гуглом, не полон: даётся только несколько первых строк каждого сообщения.)
У вышеприведённого примера есть эквивалентный FGHI URL:
Жетоном для этого вида является "totr" (нечувствительным к регистру, и без кавычек).
В этом режиме просмотра читатель видит ленту сообщений, которая подобна описанной в предыдущем разделе (то есть содержит заголовки сообщений и соответствующие тела сообщений), но содержит только вершину каждого из деревьев ответов, то есть содержит только сообщения без кладжей REPLY, но не содержит ответы на них, или ответы на ответы, или какие- либо из последующих ответов. Однако общее количество всех ответов в дереве, тем не менее, МОЖЕТ отображаться подле вершины каждого дерева.
7.2.3.9. Список вершин деревьев -+-----------------------------
Жетоном для этого вида является "topl" (нечувствительным к регистру, и без кавычек).
Этот режим просмотра почти точно подобен ленте вершин деревьев (см. предыдущий раздел). Есть только одно отличие: в этом режиме просмотра тело сообщения вершины каждого дерева не отображается, и, следовательно, читатель видит только список заглавий и других подробностей заголовка таких сообщений, и НЕОБЯЗАТЕЛЬНЫЙ счёт откликов в деревьях.
Жетоном для этого вида является "expa" (нечувствительным к регистру, и без кавычек).
Этот режим просмотра почти точно подобен дереву ответов (см. раздел 7.2.3.4). Есть только одно отличие: в этом режиме просмотра тело сообщения каждого из сообщений дерева также отображается, и, следовательно, читатель видит не только заглавие и другие подробности заголовка такого сообщения, но также и текст сообщения. Заголовок и тело любого отвечающего сообщения НАДОБНО в равной степени выделить отступом под тем сообщением, на которое это сообщение отвечает.
Жетоном для этого вида является "exbr" (нечувствительным к регистру, и без кавычек).
Этот режим просмотра почти точно подобен ветви ответов (см. раздел 7.2.3.5). Есть только одно отличие: в этом режиме просмотра тело сообщения каждого из сообщений ветви также отображается, и, следовательно, читатель видит не только заглавие и другие подробности заголовка такого сообщения, но также и текст сообщения. Заголовок и тело любого отвечающего сообщения НАДОБНО в равной степени выделить отступом под тем сообщением, на которое это сообщение отвечает.
Некоторые ответы появляются свёрнутыми, однако МОГУТ быть вручную развёрнуты их читателем.
7.2.3.12. Плоское дерево -+----------------------
Жетоном для этого вида является "flat" (нечувствительным к регистру, и без кавычек).
В этом режиме просмотра отображаются только сообщения, принадлежащие к некоторому дереву ответов, то есть какое-либо сообщение, в котором нету кладжа REPLY, и все ответы на это сообщение, и все ответы на эти ответы, и так далее.
Однако, порядок этих сообщений обуславливается только порядком сортировки сообщений (см. раздел 7.2.6), а не их положением в дереве ответов. В этом смысле этот режим просмотра весьма похож на ленту сообщений (см. раздел 7.2.3.7), но есть два важных различия:
1) Лента сообщений МОЖЕТ содержать сообщения из нескольких деревьев ответов (например, area://FTSC_Public?view=reel означает вид, содержащий все сообщения из FTSC_Public); вид плоского дерева, как раз наоборот, состоит только из сообщений из одного дерева ответов.
2) Лента сообщений содержит только сообщения, принадлежащие к итоговому множеству фильтрованных сообщений, и она содержит все такие сообщения. Плоское дерево изначально сосредоточено на первом сообщении из итогового множества фильтрованных сообщений, но отображает всё то дерево, к которому первое сообщение принадлежит. Некоторые из отображаемых сообщений не принадлежат к этому итоговому множеству, и некоторые сообщения итогового множества не отображаются первоначально (поскольку они не принадлежат к тому же самому первоначальному дереву, к которому принадлежит первое итоговое сообщение).
Поэтому сообщениям, которые принадлежат к итоговому множеству фильтрованных сообщений, НАДОБНО оказываться подсвеченными (для того чтобы читатель способен был отличить их от других сообщений), и СЛЕДУЕТ предоставить какие-нибудь навигационные элементы, чтобы читатель был способен перепрыгивать к следующему (или к предыдущему) сообщению итогового множества (если оно содержит более одного сообщения). Если такой прыжок помещает в фокус сообщение из другого дерева, тогда отображаемое дерево ДОЛЖНО быть заменено тем другим деревом, которое содержит сообщение, бывшее целью пользовательского перепрыгивания.
Аналогии в доFGHIном мире:
*) Keyhole BBS (Google Earth Community Forum), если кнопка 'Threaded' (в верхнем правом углу) не нажата: http://tinyurl.com/4l6e3g
Жетоном для этого вида является "flbr" (нечувствительным к регистру, и без кавычек).
Этот режим просмотра подобен плоскому дереву (см. предыдущий раздел), со следующими отличиями:
1) Прежде построения вида, первое из сообщений (согласно порядку сортировки сообщений, см. раздел 7.2.6) отыскивается в итоговом множестве сообщений (которое определено фильтрами сообщений). Вместо полного дерева отображается только ветвь, начинающаяся от этого первого сообщения. Первое сообщение итогового множества становится корнем этой ветви.
2) Всякий раз, когда читатель перепрыгивает к любому другому сообщению из итогового множества сообщений, отображается новая ветвь ответов, начинающаяся с этого сообщения как от нового корня ветви.
3) Читателю МОЖЕТ быть дана гиперссылка (или любой другой элемент интерфейса), которая может быть использована для перехода на один уровень выше от корня ветви, если он не является корнем дерева. В этом случае родительское сообщение корня ветви и (или) верхнее сообщение всего дерева МОГУТ быть показаны прямо над ветвью (хотя их СЛЕДУЕТ аккуратно пометить неактивным серым цветом или хотя бы иначе подсветить, чтобы читатель был способен отличить их от сообщений, непосредственно принадлежащих к ветви).
7.2.3.14. Календарь -+-----------------
Жетоном для этого вида является "cale" (нечувствительным к регистру, и без кавычек).
В этом виде показывается список лет, и (или) список месяцев, и (или) календарь, т. е. таблица дат месяца и соответствующих дней недели, для одного месяца или нескольких месяцев. Дни и месяцы связаны с сообщениями из итогового множества фильтрованных сообщений: если есть такие сообщения, написанные в показанную дату, тогда дата эта ДОЛЖНА оказаться подсвечена в календаре, и число, счёт таких сообщений, ДОЛЖНО появиться подле этой даты, и месяц МОЖЕТ тоже оказаться подсвеченным (особенно если есть отображённые пустые месяцы, т. е. месяцы, не содержащие сообщений итогового фильтрованного множества). Когда выстраиваются взаимосвязи между датами и сообщениями, дата сравнивается с местным временем сообщения, если только необязательный параметр "usetz" не присутствует в URLе; если "usetz" присутствует, то должно использоваться UTC (см. раздел 7.2.1.2.10).
Подсвеченные даты ДОЛЖНЫ быть некоторыми элементами интерфейса (например, гиперссылками), которые обеспечивают читателя возможностью читать дневную порцию фильтрованных сообщений из итогового множества только за один тот день. Именам непустых месяцев также СЛЕДУЕТ обеспечивать возможность читать долю сообщений только за тот месяц. В URLовом смысле, эти элементы интерфейса добавляют к текущему URLу фильтр "time", соответствующий их дате (месяцу), сужая фильтрованное множество, а также они изменяют параметр "view", поскольку эта дневная (месячная) доля сообщений осматривается, естественно, не как календарь. Чтобы определить режим просмотра дня (месяца), браузер МОЖЕТ просто проанализировать параметр "view" текущего URLа (но принимая во внимание только жетоны после "cale"), или он МОЖЕТ последовать своей собственной конструкции или своим настройкам (по умолчанию или заданным читателем).
Пустые годы НЕ СЛЕДУЕТ показывать вообще. Пустые месяцы МОГУТ также не быть показанными. Но браузер НЕ ДОЛЖЕН пропускать пустые дни в непустом месяце, поскольку это обыкновенно делает календарь неуютным физически.
*) Министерство природных ресурсов Российской Федерации (http://www.mnr.gov.ru/) реализовало календарь в левом столбце сайта; если жмякнуть по активной дате, появляется список сообщений (новостей) для этой даты.
*) Архив газеты на http://kp.ru/daily/archive/ подсвечивает непустые дни; каждая из дат является гиперссылкою на ленту вершин деревьев (статей), где комментарии читателей скрыты, и даже тела статей отображаются лишь частично.
Жетоном для этого вида является "mapm" (нечувствительным к регистру, и без кавычек).
В этом режиме просмотра показывается карта, которая представляет географические местоположения, указанные в сообщениях, принадлежащих итоговому множеству. (См. подразделы 7.2.1.5.1-7.2.1.5.3.) Такие местоположения изображаются значками (для точек, определённых кладжами GEO), прямоугольниками (для областей, определённых кладжами GEOBOX), и ещё более сложными очертаниями (определённых кладжами GEOKML; они появляются, если браузер способен отображать KML или перенаправлять вид во внешний отображатель).
Кликая или нависая над такими изображениями своей мышью, читатель достигает сообщений и читает их тексты. Если несколько сообщений привязаных к одной и той же географической точке или прямоугольнику или очертанию, то им СЛЕДУЕТ отображаться совместно (в соответствии с порядком сортировки сообщений). Чтобы определить режим просмотра этой геопометки, браузер МОЖЕТ просто проанализировать параметр "view" текущего URLа (но принимая во внимание только жетоны после "mapm"), или он МОЖЕТ последовать своей собственной конструкции или своим настройкам (имеющимся по умолчанию или настроенным читателем).
Аналогии в доFGHIном мире:
*) Демонстрационный Flash-ролик на домашней странице http://mirtesen.ru/ помещает на видном месте несколько сообщений и форумов (или чатов); они сгруппированы на карте в соответствии с местонахождением их чата или отправителя (так что сайт этот также является примером для следующего подраздела).
Жетоном для этого вида является "smap" (нечувствительным к регистру, и без кавычек).
Этот вид аналогичен предыдущему (см. предыдущий раздел); единственная разница состоит в том, что показываются не местонахождения сообщений, а местонахождения отправителей сообщений. Географические координаты отправителей сообщений собираются из ноудлистов и пойнтлистов (см. раздел 7.2.1.5.4) или из кладжей ORIGEO (см. раздел 7.2.1.5.5). Эти местонахождения всегда бывают просто точками, никогда не бывают областями или очертаниями.
Жетоном для этого вида является "glom" (нечувствительным к регистру, и без кавычек).
Этот вид совершенно аналогичен карте сообщений (см. раздел 7.2.3.15), но использует глобус земного шара (вместо карты) в качестве фона для значков и прямоугольников и очертаний.
Жетоном для этого вида является "sglo" (нечувствительным к регистру, и без кавычек).
Этот вид совершенно аналогичен карте отправителей (см. раздел 7.2.3.16), но использует глобус земного шара (вместо карты) в качестве фона для значков, символизирующих отправителей.
Аналогия в доFGHIном мире:
*) Служба Mail to GE читает координаты отправителя e-mail (которым является олень в ошейнике) и показывает их на фотоглобусе Google Earth:
7.2.3.19. Список кодированных объектов -+------------------------------------
Жетоном для этого вида является "objs" (нечувствительным к регистру, и без кавычек).
В этом виде читатель видит список всех объектов, которые были закодированы (см. раздел 7.2.2) внутри сообщений эхопочты, принадлежащих к итоговому множеству сообщений (ко множеству, определённому фильтрами сообщений). Читатель снабжается некими средствами для доступа к каждому из этих объектов (вероятнее всего, даётся гиперссылка для каждого из объектов).
Если встречаются несколько объектов, имеющих одно и то же имя, они появляются один возле другого; браузер МОЖЕТ использовать порядок сортировки сообщений (см. раздел 7.2.6), чтобы определить порядок таких объектов в соответствии с порядком сообщений, в котором объекты были отосланы. Браузер также МОЖЕТ применять некоторые из предложенных порядков сортировки ко всему списку объектов (например, "sort=siz" МОЖЕТ значить, что список объектов НАДОБНО отсортировать по размеру объектов); однако, в этом случае значение имеют качества объектов, а не качества сообщений (в вышеприведённом примере, размеры объектов вместо размеров сообщений).
7.2.3.20. Эхолист -+---------------
Жетоном для этого вида является "elst" (нечувствительным к регистру, и без кавычек).
Этот режим просмотра почти точно подобен списку вершин деревьев (см. раздел 7.2.3.9). Есть только одно отличие: в этом режиме просмотра не деревья, а целые области эхопочты появляются свёрнутыми (сокращёнными) до одной или до немногих нескольких строк текста. Стало быть, для каждой из эхопочтовых областей, перечисленных в URLе (или только для тех эхопочтовых областей, которые содержат ненулевое количество сообщений, принадлежащих к итоговому множеству, если в URLе есть фильтры), читатель видит ареатаг эхопочтовой области, описание области (как оно было дано пользователем браузера в некоторых настройках, или как оно было дано в некоем официальном CSV- или XML-эхолисте, изготовленном региональным эхокоординатором или некоторым эхобонмастером), и МОЖЕТ видеть полный счётчик сообщений в каждой эхопочтовой области и счётчик только тех сообщений, которые принадлежат к итоговому множеству, и счётчик ещё не прочитанных сообщений. (Все три счётчика НЕОБЯЗАТЕЛЬНЫЕ.)
Браузер МОЖЕТ показывать более пространный список эхопочтовых областей, нежели список, данный в обязательной части URLа, или нежели список областей, участвующих в итоговом множестве сообщений. Например, браузер МОЖЕТ показывать, в соответствии со своим устройством и (или) пользовательскими настройками, полный список эхопочтовых областей, доступных на фидонетовской станции, и даже одну или более нетмейловую область, и (или) область порченой почты, и (или) дьюполовку, вместе с ними. Однако в таком случае браузеру НАДОБНО тщательно подсветить и сделать тусклыми элементы эхолиста, чтобы читатель стал способен увидеть, какие области были даны в URLе, и какие области содержат хотя бы одно сообщение из итогового множества сообщений.
Аналогии в доFGHIном мире:
*) GoldEd+ входит в режим ареалиста (в вид эхолиста) после того, как бывает запущен
*) LiveJournal показывает разделённый запятыми список "добавленных в друзья" блогов и наблюдаемых сообществ и RSS-потоков на странице пользовательского профиля, такой как http://brad.livejournal.com/profile
Этот режим просмотра, вероятно, является лучшим режимом просмотра по умолчанию, если URL изначально не содержал ни ареатагов, ни необязательных параметров (например, просто "area://").
Порядок сортировки сообщений в этом виде не применяется, поскольку нету видимых сообщений. Типы и группы областей МОГУТ приниматься в рассмотрение при сортировке.
7.2.4. Управление видимостью кладжей и скрытых строк -+--------------------------------------------------
Этот раздел приводится для сведения. Его подраздел приводится для указания.
Кладжи (также известные под названием кладжевых строк или управляющих параграфов) -- это специальные строки, внедряемые в текстовое тело фидонетовского сообщения. Иногда кладжи обеспечивают поддержку новой адресации и другой управляющей информации, иногда они содержат элементы вспомогательных сведений об авторе сообщения (его местонахождение, номер ICQ, Jabber ID, реальное имя, играющая музыка, нынешнее настроение, и т. п.). См. технические подробности в FTS-4000.
И сказано в FTS-4000, что содержимое кладжей предназначается для программ, обрабатывающих сообщение (или копии сообщения), а не для демонстрации на уровне пользовательского интерфейса.
Фидонетовские сообщения обыкновенно содержат и некоторые другие специальные строки той же природы, предназначенные для программ, обрабатывающих сообщение, и обычно скрытые от пользователя. Однако эти скрытые строки не начинаются с символа SOH (Ctrl+A, ASCII 1), и оттого не являются кладжами. Штампы seen-by, например, являются скрытыми строками.
Пользователи обычно бывают способны указать (в пользовательских настройках, или просто горячими клавишами), какие скрытые строки и кладжи скрыты, а какие показываются в их браузерах Фидонета. Например, модераторы используют скрытые строки для контроля над распространением их эхоконференций. Многие нестандартные кладжи (в т. ч. местонахождение, номер ICQ, Jabber ID, реальное имя, играющая музыка, нынешнее настроение и проч.) предназначены для прочитывания людьми, а оформляются как кладжи для того, чтобы их легко могли спрятать те читатели, которых раздражают заголовки излишнего размера.
Если автор некоторого area-адреса чувствует, что некоторый кладж и (или) некоторая скрытая строка означенного сообщения (или сообщений) содержит значимую информацию, тогда автор МОЖЕТ дополнить этот URL необязательным параметром, чтобы превозмочь пользовательские настройки и показать желаемый кладж или скрытую строку.
Значение необязательного параметра "kl" содержит регулярное выражение; если остатком URLа оказывается означено сообщение (или несколько сообщений), тогда браузеру Фидонета, когда он показывает тело (тела) этого сообщения (этих сообщений) своему пользователю, НЕ СЛЕДУЕТ скрывать ни один из тех кладжей или скрытых строк, которые соответствуют данному выражению.
Подробности о регулярных выражениях см. в приложении A.
При проверке кладжа на соответствие регулярному выражению символ SOH (Ctrl+A, ASCII 1) ДОЛЖЕН опускаться. Например, выражение /^[PT]ID/ ДОЛЖНО соответствовать как кладжу "PID", так и кладжу "TID", хотя SOH лежит между началом строки (^) и первым символом кладжа ([PT]) в каждом из кладжей.
Стало быть, регулярные выражений "kl=" отличаются от регулярных выражений "find=" для кладжей (см. подраздел 7.2.1.4), и выражения "kl=" короче.
Замечание: для выражения "kl=" флаг "/m" не является необходимым, поскольку конструкция "^" и так соответствует началу каждого кладжа.
код URLа: ...&kl=/path/i выражение: /path/i подойдёт: PATH: 5030/1543 966 5020/4441 5080/1003 5020/830 подойдёт: Now playing: Children of Dune - The Golden Path
код URLа: ...&kl=/.*/ выражение: /.*/ что оно значит: Браузеру НАДОБНО показать все кладжи и скрытые строки сообщения (сообщений).
Браузер Фидонета МОЖЕТ, согласно своему устройству и настройкам, скрывать части отображаемых сообщений в некоторых случаях:
*) Если итоговое множество фильтрованных сообщений содержит результаты поиска (то есть если присутствует фильтр "find" или подобный ему фильтр; см. раздел 7.2.1.4), браузер МОЖЕТ показать только релевантные части сообщений (то есть только найденные слова и некоторые соседние слова для обеспечения контекста).
*) Если вид (см. раздел 7.2.3) древоподобен, браузер МОЖЕТ скрывать тела сообщений (и показывать только некоторые заголовки) тех сообщений, которые принадлежат к некоторым глубоким подветвям ответов (например, показать ответы, и ответы на эти ответы, но сократить ответы на ответы на ответы).
*) Если вид не является видом единственного сообщения (см. раздел 7.2.3.2) и тело некоторого сообщения слишком крупное, то тело МОЖЕТ быть отсечено после некоторого предела (чтобы сохранить читаемость вида); в этом случае СЛЕДУЕТ предусмотреть гиперссылку, ведущую к полной версии этакого сообщения.
*) Некоторая разметка в тексте (или гипертексте) сообщения МОЖЕТ обозначать, что части этого сообщения НАДОБНО спервоначалу показываться сокращённою, хотя позднее её МОЖЕТ развернуть пользователь. В том есть нужда для сокрытия спойлеров (сиречь комментариев, раскрывающих детали сюжета книги, или пьесы, или видеоигры, или фильма), и (или) для сокрытия крупных фотографий (которые способны в противном случае сделать отображаемую страницу слишком крупною и повлиять на её удобочитаемость), и т. д. Например, LJ определяет на http://www.livejournal.com/support/faqbrowse.bml?faqid=75 элемент lj-cut, и некоторая эквивалентная разметка обрезки МОЖЕТ быть предусмотрена при гейтовании RSS-потоков некоторых LJ-блогов в эхопочтовые области Фидонета.
Однако, если в URLе присутствует необязательный параметр "full", браузеру НЕ СЛЕДУЕТ скрывать никакие части сообщений. Значение параметра "full" игнорируется; только его присутствие или отсутствие определяет поведение браузера. РЕКОМЕНДУЕТСЯ указывать пустое значение и не использовать символ "=", тем самым удерживая длину URLов "area://..." в разумных пределах.
7.2.6. Порядок сортировки сообщений -+---------------------------------
Когда итоговое множество сообщений содержит более одного сообщения, они появляются одно за другим по порядку; это порядок сортировки сообщений.
Обыкновенно только конструкция или пользовательские настройки браузера определяют, как сортируются сообщения. Однако, в некоторых обстоятельствах, автор URLа МОЖЕТ пожелать предложить один или более порядков сортировки, которые он (или она) почитают нужными.
Значение необязательного параметра "sort" содержит либо один жетон сортировки, либо список разделённых пробелом жетонов сортировки.
Каждый из жетонов сортировки является коротким словом или сокращением (не чувствительным к регистру), которое соответствует предлагаемому порядку сортировки. Длина жетона всегда равна трём символам. Вот все возможные жетоны, в алфавитном порядке:
*) add (его определение дано в разделе 7.2.6.7) *) are (его определение дано в разделе 7.2.6.11) *) chr (его определение дано в разделе 7.2.6.3) *) cit (его определение дано в разделе 7.2.6.10) *) ori (его определение дано в разделе 7.2.6.9) *) rel (его определение дано в разделе 7.2.6.4) *) sen (его определение дано в разделе 7.2.6.8) *) siz (его определение дано в разделе 7.2.6.6) *) sub (его определение дано в разделе 7.2.6.5) *) uns (его определение дано в разделе 7.2.6.2)
Фидонетовский браузер МОЖЕТ полностью проигнорировать параметр "sort", согласно пользовательским настройкам браузера или настройкам по умолчанию. Если браузер решает учесть параметр, тогда браузеру СЛЕДУЕТ взять первый данный жетон и применить предлагаемый жетоном порядок сортировки. Если браузер не способен применить предложенный порядок сортировки (не предполагается, что все фидонетовские браузеры способны применить все возможные порядки сортировки, перечисленные в следующих подразделах этого раздела), тогда браузеру СЛЕДУЕТ взять следующий жетон и выяснить, способен ли он применить порядок сортировки, который этот жетон предлагает, и так далее. (И если в итоге ни один из жетонов не предлагает порядок сортировки, который браузер способен применить, тогда параметр "sort" ДОЛЖЕН наконец быть проигнорирован.)
Каждому жетону МОЖЕТ предшествовать знак "-", который значит, что соответствующий порядок ДОЛЖЕН идти в обратную сторону. Например, жетон "chr" означает хронологический порядок сообщений (наиболее недавние сообщения являются последними), но жетон "-chr" означает обратный хронологическому порядок сообщений (старейшие сообщения идут последними по порядку).
Если группа сообщений имеет одну и ту же позицию согласно первому встретившемуся порядку сортировки (из применимых порядков), то следующий встретившийся (применимый) порядок сортировки применяется при сортировке сообщений внутри этой группы.
Например, если браузеру встречается следующий URL:
(где знаками "+" представлены пробелы, см. раздел 5.2.2.4) и в браузере не реализована сортировка по названию города (которая соответствует жетону "cit"), но в браузере реализована сортировка по имени отправителя (которая соответствует жетону "-sen"), тогда браузеру СЛЕДУЕТ отсортировать сообщения в обратном алфавитном порядке имён их отправителей (для английских имён это было бы от "Z" до "A"); если встречаются сообщения от одного и того же отправителя (или от тёзок), тогда такие группы сообщений дополнительно сортируются в соответствии с хронологическим их порядком (который соответствует жетону "chr"); всё это происходит, если браузер не решит совсем проигнорировать параметр "sort" (и предлагаемую в нём сортировку).
Если в URLе несколько параметров "sort", и если браузер не собирается их игнорировать, тогда браузер МОЖЕТ дать выбрать пользователю, или МОЖЕТ последовать каким-либо предпочтениям, установленным в его (браузера) настройках.
Автору URLа не ТРЕБУЕТСЯ заучивать все жетоны; ему (или ей) НАДОБНО быть способным скопировать URL с адресной панели браузера (или с любого другого в равной степени удобного элемента интерфейса браузера), и поэтому СЛЕДУЕТ обеспечить настройку, чтобы выбирать, отображаются ли пользовательские изменения порядка сортировки на адресной панели (в параметре "sort=..." URLа) или просто внутренне принимаются во внимание браузером (так что URL на адресной панели не содержит параметра "sort=...", если считается, что нет в нём нужды).
7.2.6.2. Без сортировки (в порядке базы сообщений) -+------------------------------------------------
Жетоном для этого порядка сортировки является "uns" (нечувствительным к регистру, и без кавычек).
В соответствии с этим порядком сортировки сообщения появляются несортированными, то есть в том же порядке, в каком хранятся в их базе сообщений. Это, вероятно, соответствует порядку, в котором они были получены: наиболее недавно полученное сообщение появляется последним по порядку. Если URL содержит несколько ареатагов и если сообщения различных областей эхопочты хранятся раздельно, тогда сообщения из старейшей базы появляются сперва, а сообщения из наиболее недавно созданной базы являются последними по порядку.
Различные сообщения НЕ МОГУТ иметь одну и ту же позицию в рамках этого порядка; если этот порядок реализован, тогда последующие жетоны ДОЛЖНЫ быть проигнорированы.
Жетоном для этого порядка сортировки является "chr" (нечувствительным к регистру, и без кавычек).
Сообщения располагаются в хронологическом порядке: наиболее недавнее сообщение появляется последним по порядку. Кладж TrueTime сообщения (см. раздел 7.2.1.2.9) используется для нахождения даты и времени сообщения; если такой кладж отсутствует, тогда используется заголовок сообщения. Если присутствует необязательный параметр "usetz" (см. раздел 7.2.1.2.10), то сообщения сортируются в соответствии с их UTC вместо местного времени.
Различные сообщения МОГУТ иметь одну и ту же позицию в рамках этого порядка (если были написаны в пределах одной и той же секунды). В таких случаях последующие жетоны сортировки НАДО принять во внимание, чтобы определить, как эти сообщения располагаются друг относительно друга.
7.2.6.4. Сортировка по релевантности -+----------------------------------
Жетоном для этого порядка сортировки является "rel" (нечувствительным к регистру, и без кавычек).
Релевантсность обозначает то, насколько хорошо соответствуют доставленные сообщения эхопочты информационным нуждам (и поисковому запросу) пользователя. Многие поисковые системы Паутины способны сортировать результаты поиска по релевантности; например, поиск Google Groups обыкновенно сортирует свои результаты по релевантности, это установлено по умолчанию:
Если URL не содержит никакого поискового запроса (то есть ни одного из параметров "find", "subj", "findsb", "to", "sender"), тогда жетон "rel" ДОЛЖЕН быть проигнорирован.
Если браузер Фидонета обрабатывает поисковый запрос, но не способен подсчитывать релевантность и сортировать по ней, тогда жетон "rel" ДОЛЖЕН быть проигнорирован.
Иначе, в соответствии с этим порядком сортировки, сообщения располагаются в порядке релевантности: наиболее релевантное сообщение появляется первым по порядку.
Различные сообщения МОГУТ иметь одну и ту же позицию в рамках этого порядка (если браузер посчитал для них одно и то же значение релевантности). В таких случаях последующие жетоны сортировки НАДО принять во внимание, чтобы определить, как эти сообщения располагаются друг относительно друга.
Когда производится поисковый запрос (то есть когда один или более из необязательных параметров "find", "subj", "findsb", "to", "sender" присутствует), но не определён порядок сортировки (то есть отсутствует параметр "sort"), тогда браузер Фидонета может принять и осуществить сортировку по релевантности.
7.2.6.5. Сортировка по теме -+-------------------------
Жетоном для этого порядка сортировки является "sub" (нечувствительным к регистру, и без кавычек).
Сообщения располагаются в алфавитном порядке их строк "Тема" (для английских тем это было бы от "A" до "Z").
Различные сообщения МОГУТ иметь одну и ту же позицию в рамках этого порядка (если их строки "Тема" одни и те же; например, когда одно из них является ответом на другое и тема не была изменена). В таких случаях последующие жетоны сортировки НАДО принять во внимание, чтобы определить, как эти сообщения располагаются друг относительно друга.
Такой порядок сортировки полезен, например, когда случается некое голосование и голосующие помещают свои голоса в строках темы их сообщений.
7.2.6.6. Сортировка по объёму -+---------------------------
Жетоном для этого порядка сортировки является "siz" (нечувствительным к регистру, и без кавычек).
В соответствии с этим порядком сортировки, сообщения располагаются в порядке их объёмов: наиболее объёмистое сообщение появляется первым по порядку.
Различные сообщения МОГУТ иметь одну и ту же позицию в рамках этого порядка (если они состоят из одного и того же количества байтов). В таких случаях последующие жетоны сортировки НАДО принять во внимание, чтобы определить, как эти сообщения располагаются друг относительно друга.
7.2.6.7. Сортировка по имени адресата -+-----------------------------------
Жетоном для этого порядка сортировки является "add" (нечувствительным к регистру, и без кавычек).
Сообщения располагаются в алфавитном порядке имён их адресатов (для английских имён это было бы от "A" до "Z"). Это имена из полей "Кому" в заголовках.
Различные сообщения МОГУТ иметь одну и ту же позицию в рамках этого порядка (если они адресованы одному и тому же человеку или каким-либо тёзкам). В таких случаях последующие жетоны сортировки НАДО принять во внимание, чтобы определить, как эти сообщения располагаются друг относительно друга.
7.2.6.8. Сортировка по имени отправителя -+--------------------------------------
Жетоном для этого порядка сортировки является "sen" (нечувствительным к регистру, и без кавычек).
Сообщения располагаются в алфавитном порядке имён их отправителей (для английских имён это было бы от "A" до "Z"). Это имена из полей "От" в заголовках.
Различные сообщения МОГУТ иметь одну и ту же позицию в рамках этого порядка (если они отправлены одним и тем же человеком или какими-либо тёзками). В таких случаях последующие жетоны сортировки НАДО принять во внимание, чтобы определить, как эти сообщения располагаются друг относительно друга.
7.2.6.9. Сортировка по адресу отправителя -+---------------------------------------
Жетоном для этого порядка сортировки является "ori" (нечувствительным к регистру, и без кавычек).
Сообщения располагаются в соответствии с порядком адресов их отправителей. Адреса эти берутся из строк ориджинов этих сообщений (см. FTS-0004).
Порядок следующий:
*) если два сообщения происходят из разных зон, сообщение с большим номером зоны идёт после сообщения с меньшим номером зоны;
*) если два сообщения происходят из одной и той же зоны, но разных сетей, то сообщение с большим номером сети идёт после сообщения с меньшим номером сети;
*) если два сообщения происходят из одной и той же зоны и сети, но разных узлов, то сообщение с большим номером узла идёт после сообщения с меньшим номером узла;
*) если два сообщения происходят из одной и той же зоны и сети и узла, но разных пойнтов, то сообщение с большим номером пойнта идёт после сообщения с меньшим номером пойнта.
Различные сообщения МОГУТ иметь одну и ту же позицию в рамках этого порядка (если они появились в Фидонете через одну и ту же первоначальную систему). В таких случаях последующие жетоны сортировки НАДО принять во внимание, чтобы определить, как эти сообщения располагаются друг относительно друга.
7.2.6.10. Сортировка по местонахождению отправителя -+-------------------------------------------------
Жетоном для этого порядка сортировки является "cit" (нечувствительным к регистру, и без кавычек).
Сообщения располагаются в алфавитном порядке физических местонахождений их отправителей (для английских названий местонахождений это было бы от "A" до "Z"). Каждое название местонахождения берётся из строки ноудлиста (поле 4, см. FTS-5000), соответствующей адресу системы отправителя (данному в строке ориджина, см. FTS-0004), или адресу босс-ноды отправителя, если отправитель является пойнтом.
(Браузеру Фидонета СЛЕДУЕТ использовать собственные местонахождения пойнтов вместо местонахождений их босс-нод, если у браузера также есть соответствующие пойнтлисты.)
Различные сообщения МОГУТ иметь одну и ту же позицию в рамках этого порядка (если их отправители живут в одном и том же городе, или деревне, или пригороде, и т. д.). В таких случаях последующие жетоны сортировки НАДО принять во внимание, чтобы определить, как эти сообщения располагаются друг относительно друга.
7.2.6.11. Сортировка по ареатагу -+------------------------------
Жетоном для этого порядка сортировки является "are" (нечувствительным к регистру, и без кавычек).
Сообщениям СЛЕДУЕТ располагаться в алфавитном порядке ареатагов, соответствующих эхопочтовым областям, из которых взяты сообщения. Сообщениям также МОЖНО располагаться в каком-либо другом порядке ареатагов (более сложном, нежели алфавитный порядок), если такой порядок продиктовывается настройками или устройством фидонетовского браузера (по аналогии с директивою AreaListSort в GoldEd+).
Различные сообщения МОГУТ иметь одну и ту же позицию в рамках этого порядка (если принадлежат к одной и той же эхопочтовой области). В таких случаях последующие жетоны сортировки НАДО принять во внимание, чтобы определить, как эти сообщения располагаются друг относительно друга.
Если браузер уже знает, что все сообщения принадлежат к одной и той же области эхопочты, тогда браузер МОЖЕТ проигнорировать жетон "are" совершенно (избавив себя от необходимости этакой сортировки), и продолжить со следующего жетона.
Когда несколько деревьев сообщений видны внутри одного и того же вида (см. разделы 7.2.3.6, 7.2.3.8, 7.2.3.9), то есть несколько подходов к тому, как сортировать деревья (т. е. разные мнения насчёт того, какому дереву НАДОБНО предшествовать какому другому дереву).
В блогосфере блогозапись (которая является вершиною дерева) считают куда более важною, нежели любой из откликов (листьев того же дерева), и оттого только вершины деревьев определяют порядок этих деревьев.
Пример:
Блогозаписи на http://brad.livejournal.com/2008/03/01/ появляются в хронологическом порядке. Комментарии, хотя некоторые из них являются более недавними, нежели те сообщения, в которых они помещены, не переменяют положение тех сообщений, в которых они помещены.
В форумах нити обсуждений часто располагают в хронологическом порядке последних ответов.
В Фидонете оба эти режима возможны, если браузер реализует необязательный параметр "leaf", который МОЖЕТ иметь один из трёх следующих значений:
*) ini (т. е. "leaf=ini" является частью URLа)
Деревья сортируются в соответствии с порядком сортировки первоначальных их сообщений.
Например, при сортировке в обратном хронологическому порядке первыми нитями обсуждения становятся те, которые были начаты недавно, даже если есть более недавние ответы в некоторых других нитях обсуждения, которые были начаты ранее, например, неделю назад или месяц назад.
Достигается "блогосферический режим" сортировки сообщений. (Примечание: чтоб также достигнуть "блогосферического режима" выборки сообщений, нужен фильтр "ttop", см. раздел 7.2.1.7).
*) all (т. е. "leaf=all" является частью URLа)
Деревья сортируются в соответствии с порядком сортировки всех их сообщений. Положение дерева по порядку равняется лучшему положению из возможных для листьев дерева.
Например, при сортировке в обратном хронологическому порядке первою нитью обсуждения становится та, которая содержит наиболее недавнее сообщение. И другой пример: если сортируем по размеру, то первой нитью обсуждения становится та, которая содержит крупнейшее сообщение.
Примечание: в этом режиме сортировки обратный порядок сортировки не является в точности противоположным порядком сортировки. Например, если нить сообщений содержит как наиболее старое, так и наиболее новое сообщение, то эта нить появится первой как в хронологическом, так и в обратном хронологическому порядке.
*) fil (т. е. "leaf=fil" является частью URLа)
То же, что и "leaf=all", но единственными сообщениями, принимаемыми во внимание (при вычислении положения дерева) являются сообщения, принадлежащие итоговому фильтрованному множеству (определяемому фильтрами, см. раздел 7.2.1).
Простой пример: если присутствует фильтр "ttop", то "leaf=fil" достигает того же результата, что и "leaf=ini".
Сложный пример: если знаменитость даёт интервью фидошному сообществу в некоторой эхе, и если присутствует фильтр "from" и значение фильтра "from" равно фидонетовскому адресу этой знаменитости, тогда в обратном хронологическому порядке первой нитью обсуждения становится та, которая содержит наиболее недавнее сообщение от знаменитости. Тем самым фэны способны отслеживать, что происходит в этих нитях (и игнорировать другие нити, в которых, вероятно, идёт отдельное междуфэнское обсуждение).
Необязательный параметр "leaf" МОЖЕТ также приниматься во внимание при сортировке ветвей одного и того же уровня дерева.
7.3. Схема "faqserv://" -+---------------------
FAQ-серверами называют фидонетовские станции, которые принимают специальные запросы, содержащие имена файлов (или алиасы) неких текстов. Такие запросы посылаются фидонетовским нетмейлом. FAQ-сервер обрабатывает запрос и посылает запрошенный текст отправителю запроса; текст посылается фидонетовским нетмейлом либо в одном письме (целиком), либо в нескольких (секциями).
Символ "/" имеет своё буквальное значение в необязательной части URLов этой схемы. Символ "/" имеет зарезервированный смысл внутри необходимой части URLа (<сервер>/<запрос>/<путь-объекта>), играя роль разделителя между частями пути. Однако внутри части <сервер> символ "/" снова ДОЛЖЕН иметь своё буквальное значение и ДОЛЖЕН появиться единожды (и только единожды!) как разделитель между частями адреса сервера.
Часть <сервер> является обязательной и ДОЛЖНА присутствовать в URLах faqserv. В этой части используется стандартная фидонетовская запись адреса, <zone>:<net>/<node>.<point>@<domain> (см. подробности в FSP-1004). Однако некоторые части адреса -- "<zone>:", "@<domain>" и (или) ".<point>" -- МОГУТ пропускаться (опять же см. подробности в FSP-1004). Часть <сервер> в URLах faqserv означает фидонетовский адрес той станции (FAQ-сервера), запрос к которой подразумевается.
Если <путь-объекта> в faqserv-адресе не пуст, то и <имя-объекта> ДОЛЖНО также быть непустым по определению, и в нём указано имя объекта, внедрённого в нетмейловый текстовый ответ, отсылаемый FAQ-сервером. Либо этот объект, либо одна из его внутренних частей является означенною согласно <путь-объекта>.
Однако нетмейловый отклик сервера МОЖЕТ содержать более одного объекта под одним и тем же именем. В этому случае означенный URLом объект является последним среди одноимённых объектов, способных быть декодированными. Определение последнего объекта дано в разделе 7.2.2.2.
Часть <запрос> в faqserv-адресе, если присутствует, НЕ ДОЛЖНА быть пустою.
Если часть <запрос> в faqserv-адресе вовсе отсутствует, тогда <путь-объекта> ДОЛЖЕН также быть пуст, и "<запрос>/<путь-объекта>" НЕ ДОЛЖНЫ приводиться вообще, и предшествующий символ "/" МОЖЕТ также быть опущен. В этом случае faqserv-адресом обозначается сам FAQ-сервер, как фидонетовская станция. Такой URL МОЖЕТ означать действие, а не ресурс; к примеру, означать добавление заданного FAQ-сервера в некоторый список или базу данных FAQ-серверов.
Однако такое действие НЕ ДОЛЖНО подразумевать отсылку каких-либо запросов к означенному серверу. Различные FAQ-серверы используют различные имена запроса по умолчанию; это может быть 'FILES', 'LIST', 'INDEX', 'HELP' или любое другое имя. Поэтому-то Единая Форма Адресации Ресурсов НЕ ДОЛЖНА ожидать, что обработчик URLа будет обладать каким-то дополнительным знанием помимо данных, указанных в самом URLе. Если требуется запрос, то соответствующая часть faqserv-адреса должна присутствовать и не быть пустою, содержа запрос (см. подробности ниже).
Если часть <запрос> в faqserv-адресе присутствует, то она содержит запрос, отсылаемый заданному серверу. URLом бывает означен либо весь отклик в целом (если <путь-объекта> пуст), либо всего лишь некоторый объект внутри отклика (если <путь-объекта> не пуст).
Если часть <запрос> присутствует в faqserv-адресе, подразумевается получение сообщения (или нескольких сообщений) нетмейлом. Однако большинство вспомогательных технических и декоративных элементов нетмейла (то есть таглайны, тиарлайны, строки ориджинов, подписи, приветствия, и т. п.) СЛЕДУЕТ устранить из текста ответа, когда нетмейл будет получен и отклик из него станет извлекаться. Полезно помнить, что отклик МОЖЕТ располагаться в нескольких сообщениях, и его секции НАДОБНО избавить ото всех их обёрток прежде, чем они будут окончательно собраны вместе.
Ресурсы, означенные в faqserv-адресах, могут появляться в качестве элементов в сложных структурах данных (например, как объекты на страницах гипертекста). Фидонетовским браузерам НАДОБНО кешировать извлечённые объекты и (или) нетмейловые письма-отклики с тем, чтоб обеспечивалось немедленное отображение прежде уже запрашивавшихся ресурсов.
Чтобы помочь в кешировании, faqserv-адрес МОЖЕТ содержать необязательный параметр "time", почти такой же, как фильтр "time" (определённый в разделе 7.2.1.2), но с нижеследующими различиями:
1) Необязательный параметр "time" ДОЛЖЕН иметь форму нижнего предела (раздел 7.2.1.2.3). Завершающий символ "-" МОЖЕТ быть пропущен, поскольку в разделе 7.2.1.2.3 он всего лишь служит признаком нижнего предела, в котором тут нет нужды.
2) Необязательный параметр "time" НЕ ДОЛЖЕН содержать пустые наиболее левые значения (раздел 7.2.1.2.3.1). К примеру, он ДОЛЖЕН всегда содержать значение года.
Если кеш фидонетовского браузера содержит означенный объект и (или) нетмейловое письмо-отклик от FAQ-сервера, тогда его первоначальные местные дата и время (с учётом "TZUTC" или "TZUTCINFO", см. подробности в FTS-4008) СЛЕДУЕТ сверить со значением параметра "time".
Если момент, данный в "time", предшествует дате и времени кешированного объекта, тогда кешированный объект СЛЕДУЕТ использовать.
Если момент, данный в "time", не предшествует дате и времени кешированного объекта, тогда кешированный объект СЛЕДУЕТ убрать из кеша, СЛЕДУЕТ перезапросить его у FAQ-сервера.
Иногда станция с FAQ-сервером не отвечает на запрос, если он не адресуется к некоторому имени служебного робота. Такое поведение является особенно естественным для тех станций, где один и тот же адрес <zone>:<net>/<node>.<point>@<domain> бывает в употреблении и у человеческих, и у автоматических адресатов, или где сосуществуют несколько роботов (например, FAQ-робот и ареафиксирующий робот).
В таких случаях к faqserv-адресу добавляется необязательный параметр "bot". Значение необязательного параметра "bot" задаёт имя необходимого адресата; оно ДОЛЖНО быть дословно скопировано в соответствующее поле сообщения в нетмейловом запросе.
Необязательный параметр "loc" определяет, копировать ли элемент <запрос> из URLа в строку заголовка нетмейла, или в тело сообщения.
Когда "loc=subj" присутствует в faqserv-адресе, то элемент <запрос> этого URLа ДОЛЖЕН быть скопирован в строку заголовка нетмейла, когда (и если) он отсылается на FAQ-сервер.
Когда "loc=body" присутствует в faqserv-адресе, то элемент <запрос> этого URLа ДОЛЖЕН быть скопирован в тело сообщения нетмейла, когда (и если) он отсылается на FAQ-сервер.
Будущие версии этого документа могут вводить ещё дальнейшие необязательные параметры в faqserv-адресах, способствуя более тесному контролю над отсылкою запроса.
7.4. Схема "fecho://" -+-------------------
Фидонетовские файлэхи немного напоминают области эхопочты в смысле передачи и распространения. Однако в них распространяются файлы вместо сообщений. Файлэхою называется разделяемая база файлов, снабжённых общим ареатагом (идентификатором файлэхи) и распространяемых через Фидонет по иерархическим и (или) p2p-подобным соединениям между отдельными системами Фидонета (узловыми и пойнтовыми).
Символ "/" имеет своё буквальное значение в необязательной части URLов этой схемы. Символ "/" имеет зарезервированный смысл внутри требуемой части URLа (<areatag>/<путь-объекта>), играя роль разделителя между частями пути. Если <areatag> (ареатаг файлэхи) содержит символ "/" в его буквальном значении, то этот символ ДОЛЖЕН быть кодирован.
Если часть <путь-объекта> пуста, то fecho-адресом бывает означена вся файлэха в целом.
Когда фидонетовский браузер открывает такой URL, он МОЖЕТ отобразить, например, список файлов, полученных фидонетовской системою через означенную файловую эху.
Такой URL МОЖЕТ содержать несколько ареатагов (разделённых пробелом). Когда фидонетовский браузер открывает такой URL, он МОЖЕТ отобразить, например, список файловых эх, означенных URLом. (И, к примеру, разрешить входить в них, как если бы они были подкаталогами, и т. п.)
Если <путь-объекта> в fecho-адресе не пуст, то его <имя-объекта> ДОЛЖНО также быть не пустым по определению, и оно указывает имя файла, доступного как результат широкого вещания через указанную файлэху.
Такой URL также может содержать несколько ареатагов (разделённых пробелом), имея в виду, что означенный файл подвергался кросс- постингу (одновременной публикации) в нескольких файловых эхах. Когда фидонетовский браузер открывает такой URL, он МОЖЕТ использовать любую из данных файловых эх для получения файла (например, если фидонетовская станция не подписана на некоторые из данных файловых эх, браузер МОЖЕТ использовать любую другую из других данных файловых эх, которая имеется в наличии). Он не обязан, к примеру, проглядывать все данные файловые эхи.
Если все ареатаги соответствуют файловым эхам, которые не доступны в системе, тогда и означенный ресурс не доступен. МОЖНО спросить пользователя, желает ли он подписаться на одну или более из данных эх. Также МОЖНО использовать FTP-зеркало (зеркала) файловой эхи (файловых эх), если доступно интернетовское соединение с таким зеркалом (с такими зеркалами). Если известно, что некоторая станция Фидонета подписана хотя бы на одну из данных файловых эх, и если она отвечает на файловые запросы, тогда файловый запрос (см. раздел 7.5) МОЖЕТ быть послан на такую станцию с целью получения файла, разосланного через данную файловую эху (через данные файловые эхи).
Каждый из заданных ареатагов МОЖЕТ содержать суффикс "@domain" (см. раздел 5.2.2.3.1).
Как это уже сообщалося выше, станция Фидонета МОЖЕТ или быть подписанною на некоторую файловую эху (с целью получения всех файлов, сообщаемых по этой эхе), или использовать некоторое внешнее хранилище файлов, сообщаемых по этой эхе (чтобы запрашивать только те файлы, в которых есть нужда, используя некоторый интерфейс типа FTP или типа фидонетовских файловых запросов). В этом последнем случае становится благоразумным кеширование файлов, полученных через такой интерфейс, чтобы эти файлы становилися немедленно доступными поздней.
Чтобы помочь в кешировании, любой fecho-адрес МОЖЕТ содержать необязательный параметр "time", почти такой же, как фильтр "time" (определённый в разделе 7.2.1.2), но с нижеследующими различиями:
1) Необязательный параметр "time" ДОЛЖЕН иметь форму нижнего предела (раздел 7.2.1.2.3). Завершающий символ "-" МОЖЕТ быть пропущен, поскольку в разделе 7.2.1.2.3 он всего лишь служит признаком нижнего предела, в котором тут нет нужды.
2) Необязательный параметр "time" НЕ ДОЛЖЕН содержать пустые наиболее левые значения (раздел 7.2.1.2.3.1). К примеру, он ДОЛЖЕН всегда содержать значение года.
Если кеш фидонетовского браузера содержит означенный объект, тогда его первоначальные местные дата и время (если их нету в наличии, то дата и время, когда файл был получен) СЛЕДУЕТ сверить со значением параметра "time".
Если момент, данный в "time", предшествует дате и времени кешированного объекта, тогда кешированный объект СЛЕДУЕТ использовать.
Если момент, данный в "time", не предшествует дате и времени кешированного объекта, тогда кешированный объект СЛЕДУЕТ убрать из кеша, СЛЕДУЕТ перезапросить его из внешнего хранилища.
Будущие версии этого документа МОГУТ вводить ещё некоторые необязательные параметры в URLах "fecho://", но фидонетовское программное обеспечение МОЖЕТ с лёгким сердцем игнорировать любые неизвестные параметры в URLах "fecho://".
7.5. Схема "freq://" -+------------------
Фидонетовские станции способны запрашивать файлы непосредственно друг у друга; даже есть протокол распределённых файловых запросов, предложенный в FSC-0071.
Символ "/" имеет своё буквальное значение в необязательной части URLов этой схемы. Символ "/" имеет зарезервированный смысл внутри необходимой части URLа (<сервер>/<запрос>/<путь-объекта>), играя роль разделителя между частями пути. Однако внутри части <сервер> символ "/" снова ДОЛЖЕН иметь своё буквальное значение и ДОЛЖЕН появиться единожды (и только единожды!) как разделитель между частями адреса сервера.
Часть <сервер> является обязательной и ДОЛЖНА присутствовать в URLах freq. В этой части используется стандартная фидонетовская запись адреса, <zone>:<net>/<node>.<point>@<domain> (см. подробности в FSP-1004). Однако некоторые части адреса -- "<zone>:", "@<domain>" и (или) ".<point>" -- МОГУТ пропускаться (опять же см. подробности в FSP-1004). Часть <сервер> в URLах freq указывает фидонетовский адрес станции, которая предоставит запрошенный файл.
Если <путь-объекта> пуст, то URLом freq бывает означена сама станция как фидонетовская система, способная предоставлять файлы по запросу.
Если <путь-объекта> в URLе freq не пуст, то его <имя-объекта> ДОЛЖНО также не быть пустым по определению, и оно указывает имя файла, запрашиваемого с дальней фидонетовской станции, указанной в части URLа <сервер>. URLом бывает означен либо сам этот файл, либо одна из внутренних частей файла (в соответствии со структурою части <путь-объекта> в URLе).
Ресурсы, означенные во freq-адресах, могут появляться в качестве элементов в сложных структурах данных (например, как объекты на страницах гипертекста). Фидонетовским браузерам НАДОБНО кешировать запрошенные файлы по мере их получения с тем, чтобы обеспечивалось немедленное отображение прежде уже запрашивавшихся ресурсов.
Чтобы помочь в кешировании, любой freq-адрес МОЖЕТ содержать необязательный параметр "time", почти такой же, как фильтр "time" (определённый в разделе 7.2.1.2), но с нижеследующими различиями:
1) Необязательный параметр "time" ДОЛЖЕН иметь форму нижнего предела (раздел 7.2.1.2.3). Завершающий символ "-" МОЖЕТ быть пропущен, поскольку в разделе 7.2.1.2.3 он всего лишь служит признаком нижнего предела, в котором тут нет нужды.
2) Необязательный параметр "time" НЕ ДОЛЖЕН содержать пустые наиболее левые значения (раздел 7.2.1.2.3.1). К примеру, он ДОЛЖЕН всегда содержать значение года.
Если кеш фидонетовского браузера содержит означенный объект, тогда его первоначальные местные дата и время (если их нету в наличии, то дата и время, когда файл был получен) СЛЕДУЕТ сверить со значением параметра "time".
Если момент, данный в "time", предшествует дате и времени кешированного объекта, тогда кешированный объект СЛЕДУЕТ использовать.
Если момент, данный в "time", не предшествует дате и времени кешированного объекта, тогда кешированный объект СЛЕДУЕТ убрать из кеша, СЛЕДУЕТ перезапросить его у фидонетовской станции, данной в URLе.
Значение параметра "size" содержит размер файла (в байтах). Если отклик означенной станции содержит файл, имеющий другой размер, тогда файл этот СЛЕДУЕТ отбросить.
Значение параметра "ed2k" содержит ed2k-хэш файла, определяемый по правилам файлообменной сети eDonkey2000 (в настоящее время поддерживаемой eMule, aMule, xMule, lphant, Shareaza и другими клиентами и сервентами). Тот же самый хэш используется в файлообменной сети Kad.
Браузер Фидонета МОЖЕТ использовать открытый исходный код или алгоритм eMule для вычисления хэшей ed2k. В этом случае, если отклик означенной станции содержит файл, имеющий другой ed2k-хэш, тогда файл этот СЛЕДУЕТ отбросить.
Если запрос файла по какой-либо причине терпит неудачу, или если пользовательские настройки повелевают использовать сеть ed2k/Kad в качестве предпочитаемого метода получения файлов, тогда браузеры Фидонета МОГУТ переводить URLы "freq://" в URLы "ed2k://" и скармливать эти последние любым ed2k-совместимым клиентам или сервентам, при условии что параметр "size" (см. предыдущий подраздел) также дан.
(последовательность символов "%%" используется здесь для обозначения того места, где разрыв строки появляется внутри URLа, а затем того места, где URL продолжается; см. подробнее в разделе 5.2.2.5).
Значение параметра "aich" содержит AICH-хэш файла, который (хэш) определяется и используется системою развитого разумного обращения с ошибками (Advanced Intelligent Corruption Handling) в eMule и eMule-совместимых сервентах файлообмена ed2k/Kad. Хэши AICH помогают вычленять и отбрасывать файловые фрагменты, испорченные в процессе передачи.
Когда браузер Фидонета переводит URLы "freq://" в URLы "ed2k://" и скармливает эти последние ed2k-совместимому клиенту или сервенту, хэши AICH МОГУТ быть добавлены к URLам "ed2k://".
(последовательность символов "%%" используется здесь для обозначения тех мест, где разрыв строки появляется внутри URLов, а затем тех мест, где URLы продолжаются; см. подробнее в разделе 5.2.2.5).
Параметр "aich" вспомогателен, ему НЕ СЛЕДУЕТ появляться в тех URLах, где параметры "ed2k" или "size" отсутствуют (и где посему эквивалентные URLы "ed2k://" НЕ МОГУТ быть построены).
Значение параметра "fecho" содержит эхотаг файловой эхи, в которой означенный файл был, более или менее недавно, распространён. Значение это МОЖЕТ содержать несколько (разделённых пробелом) эхотагов, если файл подвергался кросс- постингу (одновременной публикации) в нескольких файловых эхах.
Если запрос файла по какой-либо причине терпит неудачу, или если фидонетовская станция подписана на данную файловую эху (так что файл немедленно доступен, в отличие от задержки, присущей файловым запросам), или если пользовательские настройки повелевают использовать файловые эхи в качестве предпочитаемого метода получения файлов, тогда браузеры Фидонета МОГУТ переводить URLы "freq://" в URLы "fecho://" и использовать эти последние самостоятельно или скармливать любым программам, управляющим файлэхопочтою.
Если URL "freq://" содержит несколько параметров "fecho", они ДОЛЖНЫ интерпретироваться, как если бы их значения были разделены пробелами внутри одного параметра "fecho", то есть файл был одновременно опубликован во всех файловых эхах, указанных в этих параметрах.
7.5.6. Расширение на основе URL для файловых запросов WaZOO -+---------------------------------------------------------
Согласно FTS-0006.002, файловый запрос WaZOO основывается на файле запроса (.REQ-файле), и каждая строка такого файла содержит следующие элементы (разделённые пробелами друг от друга):
*) Имя запрошенного файла. Этот элемент обязателен.
*) Пароль на получение запрошенного файла. Этот элемент необязателен и ему всегда предшествует восклицательный знак (символ "!"), чтобы отличить его от другого необязательного элемента.
*) Тип обновления и время. Этот элемент необязателен, и ему всегда предшествует плюс ("+") или минус ("-"), чтобы обозначить тип обновления и отличить этот необязательный элемент от другого.
Если система, которая отсылает запрос, способна создавать URLы FGHI, она МОЖЕТ расширить эту строку ещё одним необязательным элементом:
*) URL "freq://" файла. Этому элементу всегда предшествует открывающая квадратная скобка ("["), а за ним следует закрывающая квадратная скобка ("]"), чтобы отличить его от других необязательных элементов.
Такое расширение на основе URL для файловых запросов WaZOO имеет следующие преимущества:
*) Оно обладает обратной совместимостью: даже если freq-сервер, обрабатывающий запрос, не знает об URLах FGHI, он всё равно МОЖЕТ прочесть имя файла в начале строки и отреагировать желаемым файлом.
*) URL "freq://" МОЖЕТ содержать необязательный параметр "fecho" (см. раздел 7.5.5), стало быть, freq-сервер, полностью подписанный на какую-либо файловую эху, МОЖЕТ обеспечивать частичную подачу её файлового материала своим клиентам.
*) URL "freq://" МОЖЕТ содержать необязательный параметр "ed2k" (см. раздел 7.5.3) и необязательный параметр "size" (см. раздел 7.5.2), и тогда freq-сервер МОЖЕТ игнорировать данное имя файла и становится способным найти даже переименованный файл, если тот имеет желаемый ed2k-хэш и размер. Freq-сервер МОЖЕТ также действовать в качестве фидонетовского интерфейса к файлообменной сети ed2k/Kad, получая файлы от каких-либо других сервентов ed2k/Kad в интересах каких-либо других систем Фидонета. Необязательный параметр "aich", если он присутствует в URLе, содействует в каждой из этих возможных задач.
*) URL "freq://" содержит адрес сервера, и оттого отклик МОЖЕТ меняться соответственным образом. Виртуальные серверы (виртуальные пойнты) МОГУТ сосуществовать на одной физической станции (как в WWW виртуальные хосты aka виртуальные серверы сосуществуют на одном вебсервере, где HTTP-отклик МОЖЕТ меняться соответственно полю "Host" входящего запроса HTTP/1.1).
*) Freq-серверы МОГУТ также принимать URLы, содержащие адреса других freq-серверов, и передавать такие запросы этим серверам. Если известно, что аплинк или даунлинк поддерживает протокол распределённых файловых запросов, предложенный в FSC-0071, тогда запрос может быть передан через этого линка посредством FSC-0071. Если известно, что аплинк или даунлинк поддерживает расширение на основе URL для файловых запросов WaZOO и принимает другие серверы в URLах, то запрос МОЖЕТ быть передан через этого линка таким же образом, каким он изначально был получен передающим узлом.
*) Freq-серверы МОГУТ также принимать некоторые URLы, не основанные на схеме "freq://"; принимая и обслуживая эти URLы, такие серверы МОГУТ действовать, например, в качестве файловых гейтов, позволяющих другим фидонетовским станциям запрашивать файлы, лежащие на FTP или HTTP, по их URLам.
Когда freq-гейт снабжает HTML-страницею, то взаимосвязанными файлами этой страницы (такими, как картинки, стилевые листы, скрипты, внедрённые объекты) он также МОЖЕТ снабжать, так что гейт избавит клиентов от необходимости запрашивать такие файлы. Однако, клиент МОЖЕТ уже иметь все эти файлы ранее запрошенными и закешированными. В таких случаях freq-гейт, пытаясь быть чрезмерно учтивым, просто создаёт ненужный траффик; вот почему гейтам СЛЕДУЕТ от такой практики воздерживаться.
Таким URLом, конечно, МОЖЕТ быть FGHI URL. Например, принимая URLы "area://", содержащие пути к файлам (см. раздел 7.1 и раздел 7.2.2), станция Фидонета, подписанная на некоторую эхопочтовую UUE-область, МОЖЕТ действовать как файловый гейт для других станций, которые не подписаны на ту же область, но иногда нуждаются в одном-двух файлах из этой области.
Флаги ноудлиста, указывающие на возможности FGHI freq (см. раздел 7.5.8) НАДОБНО принимать во внимание, когда составляется и отсылается файловый запрос.
Ранее (в догипертекстовом Фидонете) предполагалось, что отклики серверов файловых запросов будут вручную обрабатываться на тех системах, которые послали запросы. Ожидалось, что принимающий пользователь запомнит имена желаемых файлов, вручную найдёт их в своих входящих после того, как freq-сервер подаст их.
Гипертекст ТРЕБУЕТ более высокого уровня автоматизации: единственным ручным действием, ТРЕБУЕМЫМ от пользователя, является жмякание мышою (или следование другим способом) по гиперссылке "freq://...".
Чтобы достигнуть такого уровня, браузер МОЖЕТ анализировать входящие, автоматически находя файлы с именами, упомянутыми в ранее посланном .REQ-файле. Однако такой анализ становится гораздо надёжнее, если freq-сервер предусматривает собственный список посланных файлов и посылает список вместе с ними (в дополнительном файле). Этот метод даёт серверу больше свободы, больше гибкости, теперь ему дозволяется переименовывать файлы, отвечать файлами с неожиданными расширениями (например, сообщениями об ошибках).
Правила (по которым файл .FUF-индекса строится) являются нижеследующими:
*) Если запрос .REQ не содержит никаких FGHI URLов (в квадратных скобках), то отклик .FUF вообще НЕ СЛЕДУЕТ строить: велики шансы того, что запрашивающий узел не знает о FGHI, и оттого отклик .FUF является просто ненужным бременем для его (её) входящих.
*) Имя файла .FUF ДОЛЖНО быть таким же, что и у файла .REQ. Например, если файл запроса был назван 00010002.REQ (как в FTS-0006), то индекс отклика ДОЛЖЕН быть 00010002.FUF
*) Каждая строка текста в файле .REQ является запросом. Если этот запрос игнорируется, соответствующая строка НЕ ДОЛЖНА появляться в .FUF-индексе отклика. Если запрос обслуживается, строка ДОЛЖНА появиться в .FUF-индексе отклика: имя файла и, затем, URL в квадратных скобках ДОЛЖНЫ присутствовать. Если URL был предоставлен в строке запроса .REQ-файла, тогда URL НАДО скопировать дословно в .FUF-файл; в противном случае URL ДОЛЖЕН быть сгенерирован freq-сервером. Если файл доставляют под тем же именем, под которым он был запрошен, имя ДОЛЖНО быть скопировано в .FUF-файл дословно (никаких изменений регистра символов, и т. п.); если файл переименован freq- сервером, или если другой файл (например, сообщение об ошибке) предоставляется вместо него, то новое имя ДОЛЖНО появиться в .FUF-файле вместо первоначального имени.
Если браузер (или какой-либо другой кусок программного обеспечения; например, специальный обработчик откликов) кеширует отклики на файловые запросы, и если полученные файлы хранятся как есть (то есть как файлы, а не как блоки данных внутри некоей базы данных), тогда СЛЕДУЕТ соединять .FUF-файлы друг с другом, создавая один-единственный объединённый индекс, в котором браузер МОЖЕТ позже, ища по URLу, найти имя любого из ранее полученных файлов.
В таком итоговом .FUF-индексе имяфайловая часть каждой строки МОЖЕТ содержать также относительный путь (относительно положения .FUF), если файлы разложены по нескольким каталогам.
В таком итоговом .FUF-индексе URLовую часть каждой строки СЛЕДУЕТ переменить, чтобы она содержала необязательный параметр "time" (см. подраздел 7.5.1), чтобы указывать, когда пришёл отклик. Сравнивая параметры "time" в URLах с параметрами "time" в тутошнем .FUF-индексе, браузер знает наверняка, есть ли нужда перезапросить файл, или кешированная копия сгодится. Даже если первоначальный штамп времени запрошенного файла не сохранился.
Примечание: формат "имяфайла [URL]" индекса файлов подобен формату файлов DESCRIPT.ION, создаваемых Download Master (aka Internet Download Accelerator). Если браузер Фидонета способен скармливать фидонетовскому мейлеру URLы "freq://" и разбирать получающиеся .FUF-индексы, то тот же браузер, наверно, способен скармливать в Download Master URLы "http://" и "ftp://" и разбирать получающиеся индексы DESCRIPT.ION. Это МОЖЕТ быть важно, если браузер Фидонета не способен сам скачивать из Интернета, и если пользователь располагается в России, или на Украине, или в Белоруссии (где Download Master является freeware).
7.5.8. Флаги ноудлиста, указывающие на возможности FGHI freq -+----------------------------------------------------------
Если фидонетовская станция способна принимать FGHI URL в файловых запросах и откликается запрошенными файлами и .FUF-индексом на каждый из таких (расширенных) .REQ-запросов, то этой станции СЛЕДУЕТ вывесить флаг FUF в соответствующей строке соответствующего ноудлиста (или пойнтлиста), в соответствии с разделом 6 ('Userflags') FTS-5001.
Пример пойнтлистовой строки (взят из FTS-5002.001 и слегка изменён):
Если станция принимает схемы URLов другие, нежели "freq://", тогда такие схемы СЛЕДУЕТ дать после флага "FUF", и каждой схеме там ДОЛЖНО предшествовать двоеточие (символ ":").
Как упомянуто выше (в разделе 7.5.6), на такую станцию МОГУТ звонить не-интернетовские узлы Фидонета (способные только к дайалапу), когда у них есть нужда в WWW-файле ("http://..."). Станция также способна снабжать файлами, декодированными из эхопочты ("area://.../filename", возможно, с дополнительными необязательными параметрами) и файлами, доступными из неких файлообменных сетей ("magnet:...").
Если станция также поддерживает многоузловое расширение файловых запросов FGHI URL (т. е. если станция принимает URLы "freq://", указывающие на другие узлы, и перенаправляет такие файловые запросы на эти узлы, и откликается результатами перенаправленных запросов), тогда флаг "FUFME" СЛЕДУЕТ использовать вместо "FUF".
Такой FUFME-узел, если способен устанавливать фидонетовские соединения как Fido-over-IP, так и по дайалапу, МОЖЕТ использоваться в качестве прокси-сервера "только дайалапными" и "только интернетовскими" узлами, когда они желают запросить файлы друг у друга, но не могут установить прямое соединение. (В таком случае "только интернетовскому" узлу НАДОБНО выбрать FUFME-прокси только из той же самой сети, где располагается конечная цель запроса: не ожидается, что узлы FUFME станут совершать международные или даже междугородние телефонные звонки.)
Фидонетовская система МОЖЕТ мочь или желать принимать файловые запросы о файлах, которые располагаются только на некоторых других системах; например, фидонетовский узел МОЖЕТ принимать файловые запросы только о файлах своих пойнтов, фидонетовский хост может принимать файловые запросы только о файлах своих даунлинков. В таком случае флаг "FUFME" НЕ ДОЛЖЕН использоваться и вместо флага "FUFME" такая станция должна вывесить флаг "FUFP" и (или) флаг "FUFD".
Флаг "FUFP", когда он появляется в ноудлистовой строке некоторой системы, означает, что файлы, располагающиеся на пойнтах этой системы, МОЖНО с неё запрашивать.
Флаг "FUFD", когда он появляется в ноудлистовой строке некоторой системы, означает, что файлы, располагающиеся на даунлинках этой системы, МОЖНО с неё запрашивать. (Флаг "FUFD" НЕ МОЖЕТ использоваться, если строка ноудлиста не начинается со статуса "Host" или "Hub", так как потребен точный список даунлинков.)
Такие станции МОГУТ использоваться для обеспечения онлайнового прокси-обслуживания ресурсов, которые в противном случае часто уходили бы в оффлайн вместе с их собственными системами. Скажем, "CM"-узел МОЖЕТ действовать как прокси-фрек-сервер для файлов, расположенных на его пойнтах, даже когда пойнты в оффлайне, а "CM"-хост или хаб может действовать как прокси для своих "TYZ"- даунлинков. (Значение "CM" и "TYZ", пожалуйста, см. в FTS-5001, разделы 5.1 и 5.7.) Чтобы задача эта была выполнена, таким проксям НАДОБНО кешировать ресурсы, запрошенные фреками, так как позднее кешированный файл МОЖЕТ быть немедленно дан как ответ на любой файловый запрос, адресованный той же фидонетовской станции и содержащий то же имя файла и тот же (или более древний) штамп времени (тем самым запрос обслуживается, даже если та станция, которой он адресован, в оффлайне). Таким проксям, однако, НАДО воздерживаться от подачи таких кешированных файлов в ответ на запросы, не содержащие параметр "time", поскольку это значило бы риск подачи старого файла людям, которым потребна новая версия его. (См. раздел 7.5.1 о необязательном параметре "time" и о его применении в кэишровании.)
Если флаг "FUF" не содержит никаких суффиксов ":протокол", то флаг этот НЕ НАДО вывешивать, когда "FUFP" и (или) "FUFD" наличествуют в той же строке ноудлиста, поскольку любой из этих флагов уже подразумевает возможность FGHI freq.
Будущие версии этого документа МОГУТ вводить ещё дальнейшие необязательные параметры во freq-адресах, способствуя более тесному контролю над тем, как запрашивается файл. Например, некоторые станции Фидонета МОГУТ отказываться отвечать или откладывать ответ на запрос файла, посланный в некоторое неприемлемое время суток или день недели; таким образом, МОГУТ появиться один или два параметра для указания того времени и дня недели, которые сделают файловый запрос сравнительно безопасным.
Программам, обрабатывающим URLы freq, НЕ СЛЕДУЕТ быть уверенными насчёт того, безопасно ли игнорировать любой из им не известных параметров. Некоторые из будущих расширений могут поразительно переменить шансы на успех файлового запроса, особенно если такой параметр будет управлять временем файлового запроса.
Если незнакомый параметр встретился в URLе freq, СЛЕДУЕТ всегда спрашивать пользователя о том, может ли этот параметр быть проигнорирован с лёгким сердцем.
Приложение A. Регулярные выражения -+--------------------------------
Необязательный параметр area-адреса способен содержать в себе регулярное выражение (регэкс). Так, в разделе 7.2.1.4 регэкс используется для указания на означенное сообщение (сообщения); в разделе 7.2.4.1 регэкс определяет, является ли видимым кладж.
В языке регулярных выражений есть несколько различных диалектов. Perl-совместимые регулярные выражения (PCRE) избраны здесь в качестве РЕКОМЕНДУЕМЫХ; это потому, что движок PCRE обладает богатым набором возможностей, и потому, что движок этот давно уж встроен в ECMAScript-совместимые браузеры современной Паутины.
Сам язык регулярных выражений лежит далеко за рамками этого документа. Статья http://en.wikipedia.org/wiki/PCRE в Википедии и имеющиеся в ней внешние ссылки, вероятно, являются лучшим начальным местом для желающих научиться написанию регэксов PCRE.
Некоторые фидонетовские браузеры имеют собственные движки языка JavaScript, и им СЛЕДУЕТ соответствовать требованиям стандарта ECMA-262, третья редакция, раздел 15.10. (Как функциональные возможности, так и форма записи тамошних регулярных выражений соответствуют способностям языка программирования Perl 5.) Остальным фидонетовским браузерам НАДОБНО использовать пакет библиотек PCRE, который является открытым программным обеспечением, написанным Филиппом Хазелем, и выложенным на http://www.pcre.org/
Фидонетовским гейтам в Паутине СЛЕДУЕТ использовать либо сам Perl, либо реализацию PCRE в PHP (функцию preg_grep(), скажем), либо другую подходящую PCRE-совместимую реализацию.
Регулярное выражение в фидонетовском адресе ДОЛЖНО всегда иметь вид
/образец/флаги
Единственным допустимым флагом (модификатором образца) в URLах Фидонета является буква "i" (если этот модификатор установлен, то буквы образца подходят как к заглавным, так и ко строчным буквам; коротко говоря, "i" означает игнорирование регистра символов).
Регулярное выражение МОЖЕТ также содержать флаг "m" (если этот модификатор установлен, то конструкции "начало строки" и "конец строки" срабатывают немедленно после или немедленно перед началом каждой новой строки проверяемого текста, соответственно, а не только в самом его начале и конце; коротко говоря, флаг "m" означает многострочный режим поиска совпадений). Однако, даже если символ "m" отсутствует, соответствующий режим ДОЛЖЕН быть задействован. Оттого символ "m" МОЖНО пропускать, даже когда соответствующий режим необходим; в поиске кладжей, к примеру (см. раздел 7.2.1.4).
Приложение B. Известные реализации -+--------------------------------
Ко времени написания сего документа известны несколько реализаций черновых редакций сего стандарта.
B.1. HellEd -+---------
HellEd является графическим браузером и редактором эхопочты и нетмейла. Изначально его разработал Trooper (Alexey Bezugly, 2:5030/1520.9).
HellEd поддерживает несколько схем FGHI URL ("netmail:", "areafix:", "echomail:", "area://"), начиная от версии HellEd 1.2.56.
B.2. FGHI URL гейт -+----------------
На одном из фидонетовских узлов Смоленска располагается служба WWW-гейта (WebBBS), позволяющая читать Фидонет из WWW посредством FGHI-адресации. Сисопом этого гейта является NoSFeRaTU (Konstantin Kuzov, 2:5019/40.1).
Гейт понимает URL-схемы "area://" и "fecho://", которым предшествует собственный WWW-адрес гейта. Например, сообщение фидонетовской эхопочты, имеющее FGHI URL
Если посетитель FGHI URL гейта использует Web-браузер, совместимый с черновым API HTML 5 registerProtocolHandler(), тогда возможно посетить http://fghi.pp.ru/handler.php и автоматически зарегистрировать URLы FGHI внутри такого браузера, так чтобы позже стало возможно набирать URLы FGHI в адресной панели браузера для получения ресурсов Фидонета через гейт. Ко времени написания сего документа необходимые HTML 5 API были реализованы в Firefox 3 и планировалися в Safari и в Opera.
B.3. NoSFeRaTU's GoldED+ -+----------------------
NoSFeRaTU также создал особую версию GoldED+, известную как NoSFeRaTU's GoldED+, которая поддерживает FGHI URL "area://" (хотя эта поддержка основана на ранних версиях черновика FGHI URL и оттого имеет свои пределы). Ранние версии NoSFeRaTU's GoldED+ использовали Web-браузер для доступа к ресурсам, означенным URLами, через FGHI URL гейт; нынешняя версия NoSFeRaTU's GoldED+ способна открывать URL локально (то есть отыскивать означенное сообщение в местной базе сообщений эхопочты).
Приложение C. Прозреваемые грядущие технологии -+--------------------------------------------
Сей стандарт (стандарт URLов FGHI) является очевидным предтечею и предвестником многих грядущих технологий, некоторые из которых мы оттого способны прозревать невозбранно. Это приложение содержит немного ранних черновиков и предпросмотровых версий возможных стандартов для этих грядущих элементов гипертекстового Фидонета.
C.1. XML-эхолисты -+---------------
Ко времени написания сего документа большинство эхолистов Фидонета принимали одну из следующих двух форм:
1) Безыскусный эхолист
Каждая строка текстового документа содержит эхотаг, затем пробел и описание эхи.
2) CSV-эхолист
Каждая строка текстового документа содержит список значений, разделённый запятыми: статус эхи, эхотаг, описание эхи, имя модератора, адрес модератора.
Использование XML для записи эхолистов приносит следующие достоинства расширяемого языка разметки:
*) данные об одной области эхопочты МОГУТ занимать несколько строк
*) возможны необязательные дочерние элементы внутри родительских
*) рядом с модераторами МОЖНО упоминать комодераторов
*) эхи могут ссылаться на URLы правил (даже на несколько URLов зеркал)
*) эхи МОЖНО огранизовывать (ярлыки, категории, и т. п.)
*) каждый эхолист МОЖЕТ содержать глобальный идентификатор соответствующего эхопочтового бона и список узлов этого бона
Блогосфера и форумы современной Паутины выстроены поверх WWW, но HTML кажется для них слишком обобщённым. Нужные элементы блогов и форумов, элементы навроде аватар или цитирования или контактов, становятся кусками несемантической разметки (HTML-иллюстрациями, HTML-блоками, разделами в подписи), так как браузеры WWW не знают о внутреннем смысле этих элементов.
Теперь рассмотрим гипертекстовый Фидонет (место, где URLы FGHI встречаются с кладжами) как место общения, как фидосферу. Кажется очевидным, что набора семантических кладжей (определённого ниже) хватит для указания всех необходимых гиперсвязей и для отражения семантических их значений. Фидосфера, выстроенная поверх FFF, обеспечивает лучшее разделение сообщения и его социальных фенечек, нежели блогосфера поверх WWW.
В нижеследующих примерах "^a" является одиночным символом SOH (Ctrl+A, ASCII 1).
Этот кладж содержит URL внешнего файла. Этот файл содержит один или более кладжей, определённых в дальнейших разделах сего документа. Браузерам Фидонета НАДОБНО пытаться добыть кладжи сперва из социального файла, а затем из фидонетовского сообщения (письма нетмейла, письма эхопочты). Если одноимённые кладжи обнаружены в социальном файле и в фидонетовском сообщении, кладж из сообщения обладает приоритетом, а кладж из социального файла игнорируется.
Такой файл, если задан, устраняет необходимость повторения большинства кладжей раз за разом в каждом из фидонетовских сообщений того же автора. Такой приоритет, если обретён, позволяет автору сообщения переопределить одно или более свойство сообщения (или автора), не трогая социальный файл и не принуждая всех читателей загружать этот файл заново.
Авторам URLов НАДОБНО должным образом задавать необязательный параметр "time" (если он наличествует для URLовой схемы их URLов) и тем способствовать кешированию их социальных файлов.
Сообщение МОЖЕТ содержать несколько кладжей SOCFILE, в каковом случае браузеры Фидонета МОГУТ выбирать любой из заданных URLов по своему усмотрению.
(В этом примере браузеры Фидонета узлов, подключённых к Интернету, МОГУТ предпочесть сервер Паутины, а прочие узлы МОГУТ предпочесть фидонетовский FAQ-сервер.)
Социальный файл ДОЛЖЕН иметь следующую внутреннюю структуру:
*) Если строка текста начинается точкою с запятою (";"), то остальная строка представляет собою имя некоторого кладжа.
*) Если строка текста начинается двоеточием (":"), остальная строка представляет собою значение кладжа, поименованного в ближайшей верхней ";"-строке. (Социальный файл МОЖЕТ содержать одну или более таких ":"-строк, представляющих собою значения одного или более одноимённых кладжей.)
Модератор МОЖЕТ принуждать авторов эхопочты к перемещению большинства их кладжей FFF в их социальные файлы, кроме самих кладжей SOCFILE, и, возможно, также кроме нескольких переменных кладжей (таких, как настроение, музыка, аватары, корни вики, и т. п.). Некоторые кладжи FFF (как QUOTE и особенно UPD) вообще НЕ СЛЕДУЕТ помещать в социальные файлы, так как эти кладжи различаются в разных сообщениях одного автора. См. подробности в соответствующих разделах ниже.
********************************************************************** EOTD END OF THE DOCUMENT ********************************************************************** --- Mithgol's NodePost * Origin: FGHI Global Headlight Ignited (2:50/88)
