Пример маршрутной таблицы
Рисунок 4.4.11.3.3. Пример маршрутной таблицы
Для того чтобы обеспечить работу с большими и сложными сетями, в IGRP введены три усовершенствования алгоритма Белмана-Форда: Для описания путей вместо простой, введена векторная метрика. Расчет комбинированной метрики проводится с использованием формулы [1]. Применение векторной метрики позволяет адаптировать систему с учетом различных видов сервиса. Вместо выбора одного пути с минимальной метрикой, информационный поток может быть поделен между несколькими путями с метрикой, лежащей в заданном интервале. Распределение потоков определяется соотношением величин комбинированной метрики. Таким образом, используются маршруты с комбинированной метрикой меньше некоторого предельного значения M, а также с метрикой меньше V*M, где V - значение вариации M (обычно задается оператором сети). Существуют определенные проблемы с вариацией. Трудно определить стратегию использования вариации V>1 и избежать зацикливания пакетов. В современных реализациях V=1. Разработан ряд мер, препятствующих осцилляциям маршрутов при изменении топологии сети.
Значения вариации, отличное от единицы, позволяет использовать одновременно два или более путей с разной пропускной способностью. При дальнейшем увеличении вариации можно разрешить не только более "медленные" сегменты пути, но и ведущие в обратном направлении, что приведет с неизбежностью к "бесконечному" циклическому движению пакетов.
Протокол маршрутизации IGRP предназначен для работы с несколькими типами сервиса (TOS) и несколькими протоколами. Под типами сервиса в TCP/IP подразумевается оптимизация маршрутизации по пропускной способности, задержке, надежности и т.д. Для решения этой задачи можно использовать весовые коэффициента K1 и K2 (формула [1] данного раздела). При этом для каждого TOS подготавливается своя маршрутная таблица. Среди мер, обеспечивающих cтабильность топологии связей, следует отметить следующее правило, которое поясняется на приведенном ниже примере.
Маршрутизатор A сообщает B о маршруте к сети 1. Когда же B посылает сообщения об изменении маршрутов в A, он ни при каких обстоятельствах не должен упоминать сеть 1. Т.е. сообщения об изменении маршрута, направленные какому-то маршрутизатору, не должны содержать данных об объектах, непосредственно с ним связанных. Сообщения об изменении маршрутов должны содержать:
- адреса сетей, с которыми маршрутизатор связан непосредственно;
- пропускную способность каждой из сетей;
- топологическую задержку каждой из сетей;
- надежность передачи пакетов для каждой сети;
- загруженность канала для каждой сети;
- MTU для каждой сети.
Следует еще раз обратить ваше внимание, что в IGRP не используется измерение задержек, измеряется только надежность и коэффициент загрузки канала. Надежность определяется на основе сообщений интерфейсов о числе ошибок.
Существует 4 временные константы, управляющие процессом распространения маршрутной информации (эти константы определяются оператором сети):
- период широковещательных сообщений об изменении маршрутов (это время по умолчанию равно 90 сек);
- время существования - если за это время не поступило никаких сообщений о данном маршруте, он считается нерабочим. Это время в несколько раз больше периода сообщений об изменениях (по умолчанию в 3 раза).
- время удержания - когда какой-то адресат становится недостижим, он переходит в режим выдержки. В этом режиме никакие новые маршруты, ведущие к нему, не воспринимаются. Длительность этого режима и называется временем удержания. Обычно это время в три раза дольше периода сообщений об изменениях маршрутов.
- время удаления - если в течение данного времени не поступило сообщений о доступе к данному адресату, производится удаление записи о нем из маршрутной базы данных (по умолчанию это время в 7 раз больше периода сообщений об изменениях маршрутов).
IGRP-сообщение вкладывается в IP-пакет, это сообщение имеет следующие поля:
version номер версии протокола 4 байта
opcode код операции
edition код издания
asystem номер автономной системы
Ninterior, Nsystem, Nexterior числа субсетей в локальной сети, в автономной системе и вне автономной системы.
checksum контрольная сумма IGRP-заголовка и данных
Version - номер версии в настоящее время равен 1. Пакеты с другим номером версии игнорируются.
Opcode - код операции определяет тип сообщения и может принимать значения:
1 - изменение; 2 - запрос
Edition - (издание) является серийным номером, который увеличивается при каждом изменении маршрутной таблицы. Это позволяет маршрутизатору игнорировать информацию, которая уже содержится в его базе данных.
Asystem - номер автономной системы. Согласно нормам Сisco маршрутизатор может входить в более чем одну автономную систему. В каждой AS работает свой протокол и они могут иметь совершенно независимые таблицы маршрутизации. Хотя в IGRP допускается "утечка" маршрутной информации из одной автономной системы в другую, но это определяется не протоколом, а администратором.
Ninterior, nsystem, и nexterior определяют числа записей в каждой из трех секций сообщения об изменениях.
Checksum - контрольная сумма заголовка и маршрутной информации, для вычисления которой используется тот же алгоритм, что и в UDP, TCP и ICMP.
IGRP запрос требует от адресата прислать свою маршрутную таблицу. Сообщение содержит только заголовок. Используются поля version, opcode и asystem, остальные поля обнуляются. IP-пакет, содержащий сообщение об изменении маршрутов, имеет 1500 байт (включая IP-заголовок). Для описанной выше схемы это позволяет включить в пакет до 104 записей. Если требуется больше записей, посылается несколько пакетов. Фрагментация пакетов не применяется.
Ниже приведено описание структуры для маршрута:
| Number | 3 октета IP-адреса |
| delay | задержка в десятках микросекунд 3 октета |
| bandwidth | Пропускная способность, в Кбит/с 3 октета |
| uchar mtu | MTU, в октетах 2 октета |
| reliability | процент успешно переданных пакетов tx/rx 1 октет |
| load | процент занятости канала 1 октет |
| hopcount | Число шагов 1 октет |
Если поле задержки содержит только единицы, место назначения недостижимо.
Пропускная способность измеряется в величинах, обратных бит/сек, умноженных на 1010. (Т.е., если пропускная способность равна N Кбит/с, то ее измерением в IGRP будет 10000000/N.). Надежность измеряется в долях от 255 (т.е. 255 соответствует 100%). Загрузка измеряется также в долях от 255, а задержка в десятках миллисекунд.
Ниже приведены значения по умолчанию для величин задержки и пропускной способности
| Вид среды | Задержка | Пропускная способность |
| Спутник | 200,000 (2 сек) | 20 (500 Мбит/c) |
| Ethernet | 100 (1 мсек) | 1,000 |
| 1.544 Мбит/c | 2000 (20 мсек) | 6,476 |
| 64 Кбит/c | 2000 | 156,250 |
| 56 Кбит/c | 2000 | 178,571 |
| 10 Кбит/c | 2000 | 1,000,000 |
| 1 Кбит/c | 2000 | 10,000,000 |
Метрика = [K1*пропускная_способность + (K2*пропускная_способность)/(256 - загрузка) + K3*задержка] * [K5/(надежность + K4)].
Если K5 == 0, член надежности отбрасывается. По умолчанию в IGRP K1 == K3 == 1, K2 == K4 == K5 == 0, а загрузка лежит в интервале от 1 до 255.
В начале 90-х годов разработана новая версия протокола IGRP - EIGRP с улучшенным алгоритмом оптимизации маршрутов, сокращенным временем установления и масками субсетей переменной длины. EIGRP поддерживает многие протоколы сетевого уровня. Рассылка маршрутной информации здесь производится лишь при измении маршрутной ситуации. Протокол периодически рассылает соседним маршрутизаторам короткие сообщения Hello. Получение отклика означает, что сосед функционален и можно осуществлять обмен маршрутной информацией. Протокол EIGRP использует таблицы соседей (адрес и интерфейс), топологические таблицы (адрес места назначения и список соседей, объявляющих о доступности этого адреса), состояния и метки маршрутов. Для каждого протокольного модуля создается своя таблица соседей. Протоколом используется сообщения типа hello (мультикастная адресация), подтверждени (acknowledgent), актуализация (update), запрос (query; всегда мультикастный) и отклик (reply; посылается отправителю запроса). Маршруты здесь делятся на внутренние и внешние - полученные от других протоколов или записанные в статических таблицах. Маршруты помечаются идентификаторами их начала. Внешние маршруты помечаются следующей информацией:
Идентификатор маршрутизатора EIGRP, который осуществляет рассылку информации о маршруте Номер AS, где расположен адресат маршрута Метка администратора Идентификатор протокола Метрика внешнего маршрута Битовые флаги маршрута по умолчанию Протокол EIGRP полностью совместим с IGRP, он обеспечивает работу в сетях IP, Apple Talk и Novell.
Пример с альтернативными маршрутами
Рисунок 4.4.11.3.2. Пример с альтернативными маршрутами
Пусть каждый из маршрутизаторов уже вычислил комбинированную метрику для системы, изображенной на Рисунок 4.4.11.3.2. Для места назначения в сети 6 маршрутизатор A вычислит метрику для двух путей, через маршрутизаторы B и C. В действительности существует три маршрута из a в сеть 6:
- непосредственно в B
- в C и затем в B
- в C и затем в D
Маршрутизатору A не нужно выбирать между двумя маршрутами через C. Маршрутная таблица в A содержит только одну запись, соответствующую пути к C. Если маршрутизатор A посылает пакет маршрутизатору C, то именно C решает, использовать далее путь через маршрутизаторы B или D.
Для каждого типа канала используется свое стандартное значение комбинированной задержки. Ниже приведен пример того, как может выглядеть маршрутная таблица в маршрутизаторе A для сети, изображенной на Рисунок 4.4.11.3.3.
Номер |
Интерфейс |
Следующий |
Метрика |
| Сеть 1 | NW 1 | Нет | Непосредственная связь |
| Сеть 2 | NW 2 | Нет | Непосредственная связь |
| Сеть 3 | NW 3 | Нет | Непосредственная связь |
| Сеть 4 | NW 2 | C | 1270 |
| NW 3 | B | 1180 | |
| Сеть 5 | NW 2 | C | 1270 |
| NW 3 | B | 2130 | |
| Сеть 6 | NW 2 | C | 2040 |
| NW 3 | B | 1180 |
Протокол IGRP
4.4.11.3 Протокол IGRP
Сегодняшняя реализация протокола ориентирована на TCP/IP. Однако, базовая конструкция системы позволяет использовать IGRP и с другими протоколами. IGRP имеет некоторое сходство со старыми протоколами, например с RIP и Hello. Здесь маршрутизатор обменивается маршрутной информацией только с непосредственными соседями. Поэтому задача маршрутизации решается всей совокупностью маршрутизаторов, а не каждым отдельно.
Для того чтобы исключить осцилляции маршрутов, протокол IGRP должен игнорировать новую информацию в течение нескольких минут после ее возникновения. OSPF-протокол вынужден использовать большую избыточность информации по сравнению с IGRP, как на уровне базы маршрутных данных, так и в процессе обмена с внешней средой.
IGRP используется в маршрутизаторах, которые имеют связи с несколькими сетями и выполняют функции переключателей пакетов. Когда какой-то объект в одной сети хочет послать пакет в другую сеть, он должен послать его соответствующему маршрутизатору. Если адресат находится в одной из сетей, непосредственно связанной с маршрутизатором, он отправляет этот пакет по месту назначения.
Если же адресат находится в более отдаленной сети, маршрутизатор перешлет пакет другому маршрутизатору, расположенному ближе к адресату. Здесь также как и в других протоколах для хранения маршрутных данных используются специализированные базы данных.
Протокол IGRP формирует эту базу данных на основе информации, которую он получит от соседних маршрутизаторов. В простейшем случае находится один путь для каждой из сетей. Сегменты пути характеризуются используемым сетевым интерфейсом, метрикой и маршрутизатором, куда следует сначала послать пакет. Метрика - то число, которое говорит о том, насколько хорош данный маршрут. Это число позволяет сравнить его с другими маршрутами, ведущими к тому же месту назначения и обеспечивающим тот же уровень QOS. Предусматривается возможность (как и в OSPF) разделять информационный поток между несколькими доступными эквивалентными маршрутами. Пользователь может сам разделить поток данных, если два или более пути оказались почти равными по метрике, при этом большая часть трафика будет послана по пути с лучшей метрикой. Метрика, используемая в IGRP, учитывает:
время задержки;
пропускную способность самого слабого сегмента пути (в битах в сек);
загруженность канала (относительную);
надежность канала (определяется долей пакетов, достигших места назначения неповрежденными).
Время задержки предполагается равным времени, необходимому для достижения места назначения при нулевой загрузке сети. Дополнительные задержки, связанные с загрузкой учитываются отдельно.
Среди параметров, которые контролируются, но не учитываются метрикой, находятся число шагов до цели и MTU (maximum transfer unit - размер пакета пересылаемого без фрагментации). Расчет метрики производится для каждого сегмента пути.
Время от времени каждый маршрутизатор широковещательно рассылает свою маршрутную информацию всем соседним маршрутизаторам. Получатель сравнивает эти данные с уже имеющимися и вносит, если требуется, необходимые коррекции. На основании вновь полученной информации могут быть приняты решения об изменении маршрутов.
Эта процедура типична для многих маршрутизаторов и этот алгоритм носит имя Белмана-Форда. (см. также описание протокола RIP, RFC-1058). Наилучший путь выбирается с использованием комбинированной метрики, вычисленной по формуле:
[(K1 / Be) + (K2 * Dc)] r [1],
где: K1, K2 = константы;
Be= пропускная способность канала (в отсутствии загрузки) * (1 - загрузка канала);
Dc = топологическая задержка;
r = относительная надежность. (% пакетов, успешно передаваемых по данному сегменту пути). Здесь загрузка измеряется как доля от 1.
Путь, имеющий наименьшую комбинированную метрику, считается лучшим. В такой схеме появляется возможность, используя весовые коэффициенты, адаптировать выбор маршрутов к задачам конечного пользователя.
Одним из преимуществ igrp является простота реконфигурации. В igrp маршрут по умолчанию не назначается, а выбирается из числа кандидатов.
Когда маршрутизатор включается, его маршрутные таблицы инициализируются оператором вручную или с использованием специальных файлов. На Рисунок 4.4.11.3.1 маршрутизатор S связан через соответствующие интерфейсы с сетями 2 и 3.
Протокол Интернет для работы с сообщениями IMAP
4.4.14.3 Протокол Интернет для работы с сообщениями IMAP
1.Команды и отклики
Соединение IMAP 4.1 подразумевает установление связи между клиентом и сервером. Клиент посылает серверу команды, сервер клиенту данные и уведомления о статусе выполнения запроса. Все сообщения, как клиента, так и сервера имеют форму строк, которые завершаются последовательностью CRLF. Получатель (клиент или сервер) воспринимает такую строку или последовательность октетов известной длины, за которой следует строка.
1.1 Протокольный отправитель клиента и протокольный получатель сервера
Любая процедура начинается с команды клиента. Любая команда клиента начинается с префикса-идентификатора (обычно короткая буквенно-цифровая строка, например A0001, A0002 и т.д.), называемого меткой (tag). Для каждой команды клиент генерирует свою метку. Имеется два случая, когда строка, посланная клиентом, не представляет собой законченную команду. В первом - аргумент команды снабжается кодом, определяющим число октетов в строке (см. описание литеральных строк в разделе “Форматы данных”). Во втором – аргументы команды требуют отклика со стороны сервера (см. описание команды authenticate). В обоих вариантах сервер посылает запрос продолжения команды, если он готов. Такой отклик сервера начинается с символа "+".
Замечание: Если, вместо этого, сервер детектирует ошибку в команде, посылается отклик завершения bad с меткой, требующей игнорирования команды и предотвращения посылки клиентом каких-либо еще запросов.
Отправитель может послать отклик завершения и в случае некоторых других команд (если одновременно исполняется несколько команд) или если данные не имеют меток.
В любом случае, ожидается запрос продолжения, клиент предпринимает в ответ соответствующие действия и читает следующий отклик сервера. Во всех вариантах клиент должен завершить отправку одной команды прежде чем послать новую.
Протокольный приемник IMAP 4.1 сервера читает строку команды, пришедшей от клиента, осуществляет ее разбор, выделяет ее параметры и передает серверу данные. По завершении команды сервер посылает отклик.
1.2 Протокольный отправитель сервера и протокольный получатель клиента
Данные, передаваемые сервером клиенту, а также статусные отклики, которые не указывают на завершение выполнения команды, имеют префикс "*" и называются непомеченными откликами.
Данные сервера могут быть посланы в ответ на команду клиента или отправлены сервером по своей инициативе. Формат данных не зависит от причины посылки.
Отклик указывает на успешное выполнение операции или на ее неудачу. Отклик использует ту же метку, что и команда клиента, запустившая процедуру. Таким образом, если осуществляется более чем одна команда, метка сервера указывает на команду, вызвавшую данный отклик. Имеется три вида отклика завершения сервера: ok (указывает на успешное выполнение), no
(отмечает неуспех) или bad (указывает на протокольную ошибку, например, не узнана команда или зафиксирована синтаксическая ошибка).
Протокольный приемник клиента IMAP 4.1 читает строку отклика от сервера. Он должен предпринять действия, в соответствии с первым символом метки "*" или "+".
Клиент должен быть готов принять любой отклик сервера в любое время. Это касается и не запрошенных данных, присланных сервером. Данные сервера должны быть записаны так, чтобы клиент мог их непосредственно использовать, не посылая серверу уточняющих запросов.
Каждое сообщение имеет несколько связанных с ним атрибутов. Эти атрибуты могут быть определены индивидуально или совместно с другими атрибутами.
Доступ к сообщениям в IMAP 4.1 осуществляется с помощью уникального идентификатора или порядкового номера сообщения.
1.3 Атрибут сообщения UID
Каждому сообщению ставится в соответствие 32- битовый код, который при использовании совместно с уникальным идентификатором образует 64-битовую последовательность, гарантирующую однозначную идентификацию сообщения в почтовом ящике. Сообщения, приходящие позднее имеют больший код UID, чем полученные ранее.
В отличие от порядкового номера сообщения, уникальные идентификаторы не образуют упорядоченной последовательности, но они работают и за пределами текущей сессии. Это позволяет осуществлять ссылки на сообщение в случае обрыва сессии [IMAP-DISC].
UID ассоциируется с почтовым ящиком и посылается в виде кода uidvalidity отклика (ok) на фазе выбора почтового ящика. Если UID из предыдущей сессии по какой-то причине не может быть использован, UID должен быть инкрементирован.
Замечание: UID для данного почтового ящика должен всегда изменяться монотонно. Если порядок записей изменен вне рамок IMAP, необходимо перегенерировать UID для данного почтового ящика, так как порядок старых значений UID в этом случае уже не будет монотонным.
Еще одной причиной не сохранения UID может служить стирание старого и создание нового почтового ящика с тем же именем. Так как имя почтового ящика не изменилось, клиент может не знать об этом и пытаться использовать старые UID. Хорошим значением UID можно считать 32-битное представление даты и времени создания почтового ящика. Вполне приемлемо и значение 1, если имеется гарантия, что это значение никогда не будет использовано повторно, даже в случае стирания и создания нового почтового ящика с тем же именем.
UID сообщения не должно изменяться в пределах сессии, его не следует изменять и от сессии к сессии. Однако если невозможно сохранить UID сообщения в последующей сессии, каждая следующая сессия должна иметь новый уникальный код идентификатора, который больше чем любой UID использованный ранее.
Атрибут порядкового номера сообщения
Этот атрибут определяет порядковый номер сообщения в почтовом ящике, начиная с 1.
Последующее сообщение всегда имеет значение этого атрибута на 1 большее, чем у предшествующего.
Допускается изменение порядкового номера сообщения на протяжении сессии. Например, когда сообщение удаляется из почтового ящика, номера всех последующих сообщений изменяются. Аналогично, новому сообщению может быть присвоен номер удаленного сообщения.
Номера сообщений могут использоваться при вычислениях, касающихся указателей. Например, если сообщение 287 в почтовом ящике, содержащем 523 сообщения, имеет UID 12345, имеется 286 сообщений, имеющих меньшее значение UID и 236 сообщений с большими UID.
1.4 Атрибут флагов сообщения
Этот атрибут представляет собой список из нуля или более именованных лексем, соотнесенный данному сообщению. Флаг устанавливается путем его добавления к этому списку и обнуляется путем его удаления. Существует два типа флагов в IMAP 4.1. Флаг может быть постоянным или действующим только на время данной сессии.
Системным флагом является флаг, чье имя определено в данной спецификации. Все системные флаги начинаются с символа "\". Некоторые системные флаги (\deleted и \seen) имеют специальную семантику, заданную вне рамок данного документа. В настоящее время определены следующие системные флаги:
| \seen | Сообщение прочитано |
| \answered | На сообщение послан ответ |
| \flagged | Сообщение "помечено" как срочное, требующее особого внимания |
| \deleted | Сообщение помечено как стертое для последующего удаления посредством expunge |
| \draft | Сообщения не является законченным (помечено, как проект). |
| \recent | Сообщение только что положено в почтовый ящик. Эта сессия является первой, где фигурирует данное сообщение; для последующих сессий это сообщение не будет иметь флага \recent. Флаг не может быть изменен клиентом. |
Серверы могут позволять клиенту создавать новые ключевые слова в почтовом ящике. Постоянные флаги клиент может устанавливать для данного сообщения или удалять на постоянной основе; таким образом, последующая сессия может воспользоваться новыми значениями флагов.
Замечание: Системный флаг \recent имеет статус флага сессии. Флаг \recent не может использоваться в качестве аргумента команды store, и по этой причине не может быть изменен вообще.
Внутренняя дата и время сообщения на сервере. Это не та дата и время, которые указаны в заголовке [RFC-822], а время и дата получения сообщения. В случае доставки сообщения посредством протокола , это должна быть дата и время доставки конечному адресату. В случае сообщений, доставленных командой IMAP 4.1 copy, это должны быть внутренняя дата и время отправителя сообщения. В случае доставки сообщения командой IMAP 4.1 append, это должна быть дата и время, заданные в описании команды append.
Атрибут размера сообщения определяет число октетов в сообщении (рассмотрен в документе [RFC-822]). Атрибут структуры конверта сообщения соответствует требованиям документа [RFC-822]. Атрибут структуры тела сообщения несет в себе информацию о структуре сообщения в соответствии с регламентациями [MIME-IMB]. Кроме доставки текстового сообщения, как это описано в RFC-822, IMAP 4.1 позволяет осуществлять передачу части текста. Можно отдельно доставить заголовок и тело сообщения или даже часть тела сообщения.
2. Состояние и диаграмма исполнения
Сервер IMAP 4.1 находится в одном из четырех состояний. Большинство команд допустимо только во вполне определенных состояниях. Если клиент пытается реализовать команду в неправильном состоянии, это рассматривается как протокольная ошибка. В этом случае сервер откликнется командой bad или no в зависимости от реализации конкретной программы.
В состоянии без аутентификации клиент должен предоставить имя и пароль, прежде чем станет доступно большинство команд. Переход в это состояние производится при установлении соединения, если только для данного соединения не была проведена предварительная аутентификация.
В состоянии аутентификации клиент идентифицирован и должен выбрать почтовый ящик, прежде чем ему станут доступны команды для работы с сообщениями. Переход в это состояние происходит при установлении соединение с предварительной аутентификацией, когда выданы все необходимые идентификационные данные или при ошибочном выборе почтового ящика.
В состояние выбора система попадает, когда успешно осуществлен выбор почтового ящика. В состояние выхода система попадает при прерывании соединения в результате запроса клиента или вследствие независимого решения сервера.
Проверка того, что агент доставки может выполнить доставку
Рисунок .13. Проверка того, что агент доставки может выполнить доставку
Процедура включает в себя следующие шаги: Идентификацию компонента Delivery в блоке запроса доставки. Если не обнаружено ни одного или более одного подходящего компонента доставки, возникает состояние ошибки. Использование атрибута ActionOrgRef компонента доставки для идентификации компонента Organisation агента доставки. Если не обнаружено ни одного или более одного подходящего компонента Organisation, возникает состояние ошибки. Если компонент Organisation для Агента доставки не имеет элемента торговой роли с атрибутом Role агента доставки, то это ошибка. Наконец, если организация, которая получила блок запроса доставки не идентифицирует компонент Organisation для агента доставки, то это ошибка.
6.3.2. Проверка компонентов Correct, присутствующих в блоке запроса
Далее проверяется то, что в блоке платежного запроса (смотри раздел 8.7) или запроса доставки (смотри раздел 8.10) присутствуют правильные компоненты. Если компоненты отсутствуют, то это ошибка.
6.3.3. Проверка авторизованности операции
Предыдущие шаги идентифицировали операционную организацию и проверяли наличие всех необходимых компонент. На данном этапе проверяется, что операционная организация авторизована для выполнения данной процедуры.
Операционная организация идентифицирует Продавца, проверяет, что с ним имеется соглашение, которое допускает выполнение операции, и что любые ограничения этого соглашения выполнены, тогда, если требуются подписи, проверяется, что они подтверждают корректные данные. Эти шаги включают в себя:
идентификацию Продавца. Это компонент Organisation с элементом торовой роли, который имеет атрибут Role со значением Продавец. Если не обнаружено ни одного или более одного подходящего элемента торговой роли, возникает состояние ошибки. проверку наличия соглашений операционных организаций с Продавцом, позволяющих выполнение операции. Чтобы решить эту задачу операционная организация должна проверить, что:| - Продавец известен и существует соглашение с операционной организацией (кассиром или агентом доставки); | |
| - им разрешено участвовать в IOTP-транзакции данного типа. Например кассир может согласиться принимать платежи в рамках операций продажи, но не не обслуживать денежные возвраты; | |
| - любые ограничения в их соглашении с продавцом выполнены, например, требуется ли подпись отклика предложения. |
Проверка корректности подписей. Если подписи необходимы, они должны быть проверены. Это подразумевает:
| - идентификацию и проверку подписей. Это включает операционную организацию, идентифицирующую компоненты подписи, которые содержат ссылки на операционную организацию (смотри 6.3.1). В зависимости от выполняемой IOTP транзакции (смотри раздел 9) может идентифицироваться одна или две подписи; |
|
| - проверку того, что компоненты подписи корректны. Это включает проверку того, что существуют элементы дайджеста в элементе Manifest, который относится к обязательным торговым компонентам (смотри раздел 6.3.3.1). |
Все компоненты Signature, содержащиеся в IOTP-сообщении должны включать элементы Digest, которые относятся к:
Id компоненту транзакции (смотри раздел 3.3.1) сообщения IOTP, которое содержит компонент подписи. Это связывает глобально уникальный IotpTransId с другими компонентами, которые определяют транзакцию IOTP; блоку ссылок транзакции (смотри раздел 3.3) первого сообщения IOTP, которое содержит подпись. Это связывает IotpTransId с информацией о сообщении IOTP, содержащемся в Id-компоненте сообщения (смотри раздел 3.3.2). Необходима проверка того, что каждый компонент подписи содержит элементы дайджеста, которые относятся к корректным данным.
Элементы Digest, которые должны присутствовать, зависят от торговой роли организации, генерирующей цифровую подпись:
если подписант является продавцом, тогда:
| - элементы дайджеста должны присутствовать во всех компонентах блока запроса, вне зависимости от компонента выбора вида платежа, который является опционным; |
| - компонента подписи, сформированной продавцом и, опционно | |
| - один или более компонентов подписи, сформированной предыдущим Кксиром в транзакции. |
Проверка того, что Кассир может осуществить платеж
Рисунок .12. Проверка того, что Кассир может осуществить платеж
Далее выполняются следующие процедуры: Идентификация платежного компонента (смотри раздел 7.9) в блоке полученного платежного запроса. Идентификация компонентов списка видов платежа и выбора вида платежа для платежного компонента. Это включает в себя:
| - идентификацию компонента списка видов платежей (смотри раздел 7.7), значение его ID-атрибута соответствует атрибуту BrandListRef платежного компонента. Если не обнаружено ни одного или более одного компонента списка видов платежа, возникает состояние ошибки. | ||
| - идентификацию компонента списка выбора вида платежа (смотри раздел 7.8), где значение его атрибута BrandListRef соответствует BrandListRef платежного компонента. Если не обнаружено ни одного или более одного компонента выбора вида платежа, возникает состояние ошибки. |
| - Элемен вида платежа (смотри раздел 7.7.1), где значение его Id-атрибута соответствует значениюатрибута BrandRef выбора вида платежа. Если не обнаружено ни одного или более одного элемента вида платежа, возникает состояние ошибки. | |
| - Протокольный элемент суммы (смотри раздел 7.7.3) является элементом, где значение его ID
атрибута соответствует величине атрибута ProtocolAmountRef в компоненте выбора вида платежа. Если не обнаружено ни одного или более одного протокольного элемента суммы, возникает состояние ошибки. |
|
| - Элемент платежного протокола (смотри раздел 7.7.5) представляет собой элемент, значение Id
атрибута которого соответствует величине атрибута PayProtocolRef в идентифицированном протокольном элементе суммы. Если не обнаружено ни одного или более одного подходящего элемента платежного протокола суммы, возникает состояние ошибки. |
|
| - Элемент валютной суммы (смотри раздел 7.7.4) представляет собой элемент, значение Id
атрибута которого соответствует величине атрибута CurrencyAmountRef в компоненте выбора вида платежа. Если не обнаружено ни одного или более одного подходящего элемента валютной суммы, возникает состояние ошибки. |
Проверяется совместимость ссылок в списке видов платежа и компонентов выбора вида платежа:
| - проверяется, что ссылка элемента существует в атрибуте ProtocolAmountRefs идентифицированного элемента вида платежа, который соответствует ID-атрибуту идентифицированного элемента суммы. Если не может быть обнаружено ни одной или более одной подходящей ссылки элемента, возникает состояние ошибки. | |
| - проверяется, что атрибут CurrencyAmountRefs идентифицированного элемента суммы, содержит ссылку элемента, которая соответствует ID-атрибуту идентифицированного элемента вылютной суммы. Если не обнаружено ни одной или более одной подходящей ссылки элемента, возникает состояние ошибки. | |
| - проверяется совместимость элементов в списке видов платежа. В частности, элементы выбранного вида платежа, суммы, платежного протокола и валютной суммы являются дочерними элементами идентифицированного компонента списка видов платежа. Если это не так, то это ошибка. |
| - идентификацию компонента Organisation для кассира. Это компонент Organisation, где его ID-атрибут соответствует атрибуту ActionOrgRef в идентифицированном элементе платежного протокола. Если не обнаружено ни одного или более одного подходящего компонента Organisation, возникает состояние ошибки. | |
| - проверку компонента Organisation, который имеет элемент Trading Role с атрибутом Role кассира. Если его нет, происходит ошибка. | |
| - наконец, если идентифицированный компонент Organisation не совпадает с полученным в блоке платежного запроса, это вызывает ошибку. |
Способ доступа к данным Агента доставки при проверке того, может ли он выполнить доставку показан на Рисунок .13.
Start
|
v
Y">Delivery
Component
|
|ActionOrgRef
|
v
Organisation
Component
|
-Trading Role
Element
(Delivery Handler)
Распределение числа официально зарегистрированных сетевых инцидентов по годам
Рисунок 1. Распределение числа официально зарегистрированных сетевых инцидентов по годам.
Ниже на Рисунок 2 показано распределение атак сети ИТЭФ по их разновидностям (Это и последующие два распределения построены студентом МФТИ А.Тарховым).
Распределение публикаций документов RFC по годам с по
Рисунок 1.2. Распределение публикаций документов RFC по годам с 1969 по 1999
Из этого распределения видно, что к 1979 году окончательно сформировался стек базовых протоколов и начался экстенсивный рост сети Интернет. По мере выявления недостатков протоколов и новых потребностей после 1989 года началась активная разработка новых направлений и приложений в Интернет.
Но все по порядку. Начнем с того, как устроен Интернет. На Рисунок 1.3 показана общая схема, которая облегчит дальнейшее обсуждение данной проблематики (буквами R отмечены маршрутизаторы-порты локальных сетей).
Каждая из сетей, составляющих Интернет, может быть реализована на разных принципах, это может быть Ethernet (наиболее популярное оборудование), Token Ring (вторая по популярности сеть), ISDN, X.25, FDDI или Arcnet. Все внешние связи локальной сети осуществляются через порты-маршрутизаторы (R). Если в локальной сети использованы сети с разными протоколами на физическом уровне, они объединяются через специальные шлюзы (например, Ethernet-Fast_Ethernet, Ethernet-Arcnet, Ethernet-FDDI и т.д.). Выбор топологии связей определяется многими факторами, не последнюю роль играет надежность. Использование современных динамических внешних протоколов маршрутизации, например BGP-4, позволяет автоматически переключаться на один из альтернативных маршрутов, если основной внешний канал отказал. Поэтому для обеспечения надежности желательно иметь не менее двух внешних связей. Сеть LAN-6 (см. Рисунок 1.3) при выходе из строя канала R2-R6 окажется изолированной, а узел LAN-7 останется в сети Интернет даже после отказа трех внешних каналов.
Широкому распространению Интернет способствует возможность интегрировать самые разные сети, при построении которых использованы разные аппаратные и программные принципы. Достигается это за счет того, что для подключения к Интернет не требуется какого-либо специального оборудования (маршрутизаторы не в счет, ведь это ЭВМ, где программа маршрутизации реализована аппаратно). Некоторые протоколы из набора TCP/IP (ARP, SNMP) стали универсальными и используются в сетях, построенных по совершенно иным принципам.
Рост числа ЭВМ, подключенных к
Рисунок 1.1. Рост числа ЭВМ, подключенных к Интернет в период 1989-98 годы (по вертикальной оси отложено число ЭВМ в миллионах)
Сегодня, когда Интернетом заинтересовались широкие массы трудящихся, и определенная часть их подключилась к расширению этой сети, стала актуальной проблема оптимального проектирования сетей и их подключения к общенациональной и международной сети Интернет.
Современные сети Интернет объединяют в единое целое многие десятки (а может быть уже и сотни) тысяч локальных сетей по всему миру, построенных на базе самых разных физических и логических протоколов (ethernet, Token Ring, ISDN, X.25, Frame Relay, Arcnet и т.д.). Эти сети объединяются друг с другом с помощью последовательных каналов (протоколы SLIP, PPP), сетей типа FDDI(часто используется и в локальных сетях), ATM, SDH(Sonet) и многих других. В самих сетях используются протоколы TCP/IP (Интернет), IPX/SPX (Novell), Appletalk, Decnet, Netbios и бесконечное множество других, признанных международными, являющихся фирменными и т.д. Картина будет неполной, если не отметить многообразие сетевых программных продуктов (Windows NT, MS Windows-97, Netware, Multinet, Lantastic и пр.). На следующем уровне представлены разнообразные внутренние (RIP, IGRP, OSPF) и внешние (BGP и т.д.) протоколы маршрутизации и маршрутной политики, конфигурация сети и задание огромного числа параметров, проблемы диагностики и сетевой безопасности. Немалую трудность может вызвать и выбор прикладных программных средств (Netscape, MS Internet Explorer и пр.). В последнее время сети внедряются в управление (CAN), сферу развлечений, торговлю, происходит соединение сетей Интернет и кабельного телевидения.
Что явилось причиной стремительного роста сети Интернет? Создатели базовых протоколов (TCP/IP) заложили в них несколько простых и эффективных принципов: инкапсуляцию пакетов, фрагментацию/дефрагментацию сообщений и динамическую маршрутизацию путей доставки. Именно эти идеи позволили объединить сети, базирующиеся на самых разных операционных системах (Windows, Unix, Sunos и пр.), использующих различное оборудование (Ethernet, Token Ring, FDDI, ISDN, ATM, SDH и т.д.) и сделать сеть нечувствительной к локальным отказам аппаратуры.
Огромный размер современной сети порождает ряд серьезных проблем. Любое усовершенствование протоколов должно проводиться так, чтобы это не приводило к замене оборудования или программ во всей или даже части сети. Достигается это за счет того, что при установлении связи стороны автоматически выясняют сначала, какие протоколы они поддерживают, и связь реализуется на общем для обеих сторон наиболее современном протоколе (примером может служить использование расширения протокола smtp - MIME). В кабельном сегменте современной локальной сети можно обнаружить пакеты TCP/IP, IPX/SPX (Novell), Appletalk, которые успешно сосуществуют.
Проектировщикам и создателям сетей приходится учитывать многие десятки факторов при выборе того или иного типа сети, сетевого оборудования, операционной системы (UNIX, MS-DOS, IRIS, Windows-NT, SOLARIS или что-то еще), программного обеспечения, внешних каналов связи (выделенный канал, коммутируемая телефонная сеть, цифровая сеть, радио или спутниковый канал) и в конце концов сервис-провайдера. За всем этим стоят как технологические проблемы, так и финансовые трудности, тяжелый выбор между дешевой и хорошей сетью.
Если вас интересуют оригинальные тексты протоколов Интернет, вы можете получить их, например, через анонимное FTP по адресу ds.internic.net (в каталоге RFC) или на нашем сервере store.in.ru/rfcs (зеркало). Эти документы можно найти и в других депозитариях.
Документы RFC делятся на стандарты, проекты стандартов, временные (экспериментальные) регламентации и предложения. Чем больше номер RFC, тем более поздней дате этот документ соответствует. О статусе тех или иных RFCможно узнать из RFC-1500 и -1780 (см. также файл std-inde.txt из того же депозитария, что и rfc-index.txt). Если вы хотите найти какой-то RFC-документ, начните с просмотра индексного файла (напр. rfc-index.txt). Первый документ RFC был выпущен в 1969 году более 30 лет тому назад. Далее темп публикаций варьировался в довольно широких пределах, в 1997-99 годах наблюдается заметный всплеск активности, связанный с потребностями мультимедиа (RTP, RSVP, PIM и т.д.), безопасностью и IPv6.Вариация публикаций документов RFC по годам представлена на рис 1.2.
Рост числа узлов WWW в период - годы
Рисунок 1.4. Рост числа узлов WWW в период 1994-99 годы
В перспективе Интернет может стать и всемирной ярмаркой товаров и услуг. Ведь клиент может не только увидеть изображение товара и ознакомиться с условиями поставки, но и в диалоговом режиме получить ответы на интересующие его вопросы, а затем одним нажатием на клавишу мышки сделать заказ на понравившийся ему товар или услугу. В принципе для этого не нужен даже номер кредитной карточки, его заменит зашифрованный соответствующим образом идентификатор пользователя (сертификат) или его IP-адрес (если он работает на своей домашней машине). Таким образом, можно будет заказывать билеты на самолет или в театр, планировать программу своего телевизора на неделю вперед и т. д.
Современные системы мультимедиа позволяют совместить телевизор, видеомагнитофон, факс и видеотелефон, причем это не фантазия на тему далекого будущего - это услуги доступные уже сегодня (при наличии широкополосного канала связи (64-512 Кбит/с)). Если вы имеете доступ к Интернет, вам уже не нужно платить за международные телефонные переговоры, вы можете сделать это с помощью ip-phone или другого аналогичного продукта, при условии что ваш партнер также имеет доступ к Интернет (данное требование в ближайшем будущем перестанет быть обязательным). Все более широкий круг услуг предлагает Интернет и в сфере развлечений. Здесь имеются игровые серверы, аренда обычных и сетевых компьютерных игр, различные конкурсы и соревнования.
Теперь рассмотрим, как строятся каналы связи (стрелки на Рисунок 1.5). В простейшем случае связь можно организовать через городскую коммутируемую телефонную сеть, для этого нужны модемы - по одному на каждой из сторон канала (
Схема обработки сетевого запроса
Рисунок 4.1.1.3.1. Схема обработки сетевого запроса
Сначала определим, что же нужно сделать для решения стоящей задачи? Чтобы обратиться к нужной ЭВМ, система должна знать ее IP-адрес, маску субсети и адрес маршрутизатора или ЭВМ, через которые можно обратиться с запросом на установление канала связи. Рассмотрим решение проблемы поэтапно. Сначала символьный адрес vxdesy.desy.de пересылается серверу имен (DNS-система может располагаться как в ЭВМ пользователя, так и в другой машине), где преобразуется в цифровой IP-адрес, пересылаемый в отклике на DNS-запрос (предварительно надо узнать его MAC-адрес). Но знания IP-адреса недостаточно, надо выяснить, где находится объект с этим адресом. На IP-адрес накладывается сетевая маска (задается при конфигурации рабочей станции), чтобы определить, не является ли данный адрес локальным. Если адрес локален, IP-адрес должен быть преобразован в Ethernet-адрес (MAC), ведь ваша ЭВМ может оперировать только с Ethernet-адресами. Для решения этой задачи посылается широковещательный (обращенный ко всем участникам локальной сети) ARP-запрос. Если адресат находится в пределах локальной субсети, то он откликнется, прислав Ethernet-адрес своей сетевой карты. Если это не так, что имеет место в приведенном примере, присылается Ethernet-адрес пограничного для данной сети маршрутизатора. Это происходит лишь в случае, если он поддерживает режим proxy-ARP. В противном случае рабочая станция должна воспользоваться IP-адресом маршрутизатора (gateway), заданным при ее конфигурации, и выявить его MAC-адрес с помощью ARP-запроса. Наконец с использованием полученного IP-адреса программа telnet формирует IP-пакет, который вкладывается в Ethernet-кадр и посылается в маршрутизатор узла (ведь именно его адрес она получила в ответ на ARP-запрос в данном примере). Последний анализирует имеющиеся у него маршрутные таблицы и выбирает, по какому из нескольких возможных путей послать указанный пакет. Если адресат внешний, IP-дейтограмма вкладывается в PPP- FDDI- или какой-то другой кадр (зависит от протокола внешнего канала) и отправляется по каналам Интернет.
В реальной жизни все бывает сложней. Во-первых, присланный символьный адрес может быть неизвестен локальной dns-системе (серверу имен) и она вынуждена посылать запросы вышестоящим DNS-серверам, во-вторых, пограничный маршрутизатор вашей автономной системы может быть непосредственно не доступен (ваша ЭВМ находится, например, в удаленной субсети) и т.д. и т.п. Как система выпутывается из подобных осложнений, будет описано позднее. Следует иметь в виду, что, например, в системе unix все виды Интернет услуг обслуживает демон inetd. Конкретный запрос (Telnet, FTP, Finger и т.д.) поступает именно к нему, inetd резервирует номер порта и запускает соответствующий процесс, после чего переходит в режим ожидания новых запросов. Такая схема позволяет эффективно и экономно работать со стандартными номерами портов (см. ). Ну а теперь начнем с фундаментальных положений Интернет.
В Интернет информация и команды передаются в виде пакетов, содержащих как исходящий адрес, так и адрес места назначения (IP-адрес имеет 32 двоичных разряда). Каждой ЭВМ в сети поставлен в соответствие уникальный адрес, появление двух объектов с идентичными IP-адресами может дезорганизовать сеть. IP-адресация поддерживает пять различных классов сетей (практически используется только три) и, соответственно, адресов (версия IPv4). Класс А предназначен в основном для небольшого числа очень больших сетей. Здесь для кода сети выделено только 7 бит, это означает, что таких сетей в мире не может быть больше 127 (27-1). Класс B выделяет 14 бит для кода сети, а класс С - 22 бита. В классе C для кода ЭВМ (host) предназначено 8 бит, поэтому число ЭВМ в сети ограничено. Самые левые биты адреса предназначены для кода класса. ip-адрес характеризует точку подключения машины к сети. Поэтому, если ЭВМ перенесена в другую сеть, ее адрес должен быть изменен. Старшие биты адреса определяют номер подсети, остальные биты задают номер узла (номер ЭВМ). В таблице 4.1.1.3.1 приведено соответствие классов адресов значениям первого октета адреса и указано количество возможных IP-адресов каждого класса.
Схема построения сети Интернет
Рисунок 1.3. Схема построения сети Интернет
В некотором смысле Интернет возник эволюционно - в начале был Bitnet, fidonet, usenet и т.д. Со временем стало ясно, что конкуренция сетей должна быть заменена их объединением, так как от этого выигрывают все и пользователи и сервис-провайдеры. Ведь объединенная сеть имеет большие информационные ресурсы, может предложить более широкий список услуг и становится по этой причине привлекательной для еще большего числа клиентов.
Технология WWW-серверов сделала Интернет важной средой для целевой рекламы, приближенной к конечному потребителю. Стремительный рост числа узлов www продемонстрирован на Рисунок 1.4. Здесь также наблюдается экспоненциальный рост. Сам факт использования Интернет для обливания грязью кандидатов во время предвыборной компании, говорит о том, что эта технология освоена и признана эффективной нашими политиками. Наше общество с удивительным упорством сначала осваивают все негативное, оставляя, очевидно, позитивное на десерт.
Схема состояний для протокола IMAP
Рисунок 4.4.14.2.1. Схема состояний для протокола IMAP
(1) Cоединение без предварительной аутентификации (отклик OK)
(2) Cоединение с предварительной аутентификацией (отклик PREAUTH)
(3) Соединение отвергнуто (отклик BYE)
(4) Успешное завершение команды LOGIN или AUTHENTICATE
(5) Успешное завершение команды SELECT или EXAMINE
(6) Выполнение команды CLOSE, или неудачная команда SELECT или EXAMINE
(7) Выполнение команды LOGOUT, закрытие сервера, или прерывание соединения
3. Формат данных
IMAP 4.1 использует текстовые команды и отклики. Данные в IMAP 4.1 могут иметь одну из следующих форм: атом, число, строка, список, заключенный в скобки или NIL.
Атом состоит из одного или более неспециализированных символов.
Число состоит из одной или более цифр и характеризует некоторое числовое значение.
Строка может иметь одну из двух форм: литерал или строка в кавычках. Литеральная форма является основной формой строки. Строка в кавычках является альтернативной формой, исключающей избыточность литеральной формы за счет ограничений, налагаемых на символы, используемые в строке.
Литерал представляет собой нуль или более октетов (включая CR и LF). Литерал начинается с октета, где хранится число символов. Этот октет заключается в фигурные скобки, за которыми следует последовательность CRLF. В случае передачи литералов от сервера к клиенту за CRLF следуют непосредственно данные. При передаче литералов от клиента серверу клиент должен подождать прихода команды продолжения, прежде чем начать пересылку данных.
Строка в кавычках представляет собой последовательность из нуля или более 7-битовых символов за исключением CR и LF, начинающуюся и завершающуюся двойной кавычкой (). Пустая строка представляется как "" или как литерал {0}, за которым следует последовательность CRLF.
Замечание: Даже если число октетов равно нулю, клиент, передающий литерал должен подождать прихода команды продолжения.
3.1. 8-битовые и двоичные строки
8-битовая текстовая и двоичная почта поддерживается посредством шифрования [MIME-IMB].
Реализации IMAP 4.1 могут передавать 8-битные или многооктетные символы в литералах, но должны это делать, только когда определен [CHARSET]. Если даже определена кодировка BINARY, незакодированные двоичные строки не могут быть разрешены. "Двоичная строка" – это любая строка из NUL символов. Реализации программ должны перекодировать двоичные данные в текстовую форму, такую как BASE64, прежде чем их пересылать. Строка с большим числом символов CTL может рассматриваться как двоичная.
3.2. Список в скобках
Структуры данных представляются в виде списков, помещенных в скобки, элементы списка разделяются пробелами. Такой список может включать в себя другие “списки в скобках”. Пустой список выглядит как () – “список в скобках” с нулевым числом членов.
3.3. NIL
Специальный атом "NIL" представляет собой указание на отсутствие каких-то определенных данных типа строка или “список в скобках”. Его следует отличать от пустой строки "" или пустого “списка в скобках” ().
4. Операционные соображения
4.1. Присвоение имени почтовому ящику
Интерпретация имен почтовых ящиков является независимой от конкретной программной реализации. Однако имя почтового ящика INBOX является специальным именем, зарезервированным для "первичного почтового ящика данного пользователя на данном сервере" (значение не зависит от использования строчных или прописных букв). Почтовые ящики могут образовывать иерархическую структуру. Если желательно экспортировать иерархию имен почтовых ящиков, имена почтовых ящиков должны быть упорядочены по буквам слева направо.
4.2. Соглашение о пространстве имен почтовых ящиков
В соответствии с соглашением первый иерархический элемент любого имени почтового ящика, который начинается с символа "#" указывает на “пространство имен” остальной части имени. Например, реализации, которые предлагают доступ к группам новостей USENET могут использовать пространство имен "#news", для того чтобы отделить пространство имен групп новостей от имен других почтовых ящиков.
Таким образом, группа новостей comp.mail. misc будет иметь имя почтового ящика "#news.comp.mail.misc", а имя "comp.mail.misc" может относиться к другому объекту (напр., к почтовому ящику пользователя).
4.3. Международное соглашение об именах почтовых ящиков
Согласно договоренности имена международных почтовых ящиков специфицированы в соответствии модифицированной версией кодировки UTF-7, описанной в [UTF-7]. Целью этих модификаций было устранение следующих проблем, связанных с UTF-7:
UTF-7 использует символ "+" для смещения; это вызывает конфликт с обычным применением "+" в именах почтовых ящиков, в частности в именах групп новостей USENET.
Кодировка UTF-7 базируется на BASE64, где используется символ "/", что вступает в конфликт с применением "/" в качестве популярного иерархического разделителя.
UTF-7 запрещает использование "\"; что противоречит применению "\" в качестве популярного разделителя.
UTF-7 запрещает использование "~", это вступает в конфликт с тем, что некоторые серверы рассматривают этот символ, как указатель на базовый каталог (home).
UTF-7 допускает разнообразные формы представления одних и тех же строк, в частности, печатные символы US-ASCII могут использоваться в закодированной форме.
В модифицированном UTF-7, печатные символы US-ASCII за исключением "&" представляются в исходном виде; то есть, символами со значениями октетов 0x20-0x25 и 0x27-0x7e. Символ "&" (0x26) представляется в виде двух октетной последовательности "&-". Все другие символы (значения октетов 0x00-0x1f, 0x7f-0xff, и все уникодные 16-битовые октеты) представляются в модифицированной кодировке BASE64, с дополнительными видоизменениями из [UTF-7]. Модифицированная BASE64 не должна использоваться для представления любых печатных символов US-ASCII, которые должны представлять самих себя.
Символ "&" используется для перехода к модифицированной кодировке BASE64 а "-" для возврата назад к US-ASCII.
Все имена начинаются с US-ASCII, и должны завершаться US-ASCII ( то есть, имя, которое заканчивается уникодным 16-битовым октетом, должно быть завершено символом "-"). Примером может служить имя почтового ящика, в котором смешаны фрагменты текста на английском, японском и китайском языках: ~peter/mail/&ZeVnLIqe-/&U,BTFw-
4.4. Размер почтового ящика и актуализации состояния сообщений
В любое время сервер может послать данные, которые клиент не запрашивал. Иногда, такое поведение системы является необходимым. Например, агенты, внешние по отношению к серверу, могут положить сообщения в почтовый ящик, изменить флаги сообщения в почтовом ящике (например, одновременный доступ в почтовый ящик нескольких агентов), или даже удалить сообщения из почтового ящика. Сервер должен автоматически послать уведомление об изменении размера почтового ящика, если такое изменение произошло в процессе выполнения команды. Сервер должен автоматически послать уведомление об изменении флагов сообщений, не требуя соответствующего запроса клиента. Имеются специальные правила для оповещения клиента сервером об удалении сообщений, чтобы избежать ошибок синхронизации (смотри также описание EXPUNGE). Программа клиента должна своевременно фиксировать изменения размера почтового ящика. Она не должна полагаться на то, что любая команда после начального выбора почтового ящика возвращает значение его размера.
4.5. Отклик в случае, когда не исполняется никакой команды
Реализациям сервера разрешается посылать непомеченные отклики (за исключением EXPUNGE), если в это время не выполняется ни одной команды. Реализации, которые посылают такие отклики, должны учитывать соображения управления трафиком. В частности, они должны либо (1) проверить, что размер данных не превосходит транспортные возможности, или (2) использовать неблокирующую запись.
4.6. Таймер автоматического отключения (Autologout)
Если сервер имеет таймер выгрузки в случае длительной пассивности, тогда такой таймер должен быть настроен на время, по крайней мере, 30 минут.
Получения любой команды от клиента в течение этого периода должно быть достаточно для сброса этого таймера.
4.7. Одновременное исполнение нескольких команд
Клиент может послать другую команду, не дожидаясь отклика на предшествующую, сервер может начать обработку другой команды до завершения обработки текущей.
Исключение может составлять случаи, когда результат выполнения одной команды зависит от выполнения других команд. Клиенты не должны посылать несколько команд, не дожидаясь результата, если возможна неопределенность из-за их взаимозависимости. Если сервер детектирует возможную неопределенность, он должен исполнить их последовательно в порядке их получения от клиента.
Наиболее очевидный пример неопределенности реализуется, например, когда последовательно выполняются команды FETCH для флагов сообщения и STORE для тех же самых флагов.
Неочевидные неопределенности возникают с командами, которые допускают немаркированный отклик EXPUNGE (команды отличные от FETCH, STORE и SEARCH), так как немаркированный отклик EXPUNGE может нарушить корректность порядковых номеров сообщений для последующих команд. Это не представляет проблем для команд FETCH, STORE или SEARCH, так как серверам запрещено посылать отклики EXPUNGE, когда исполняется одна их этих команд. Следовательно, если клиент посылает любую команду, отличную от FETCH, STORE или SEARCH, он должен ждать отклика, прежде чем посылать команду, содержащую номер сообщения. Например, следующая последовательность команд (без ожидания) является некорректной:
FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
CHECK + FETCH
Ниже представлены примеры последовательностей, не требующих ожидания завершения предшествующих инструкций:
FETCH + STORE + SEARCH + CHECK
STORE + COPY + EXPUNGE
5. Команды клиента
Ниже описаны команды IMAP 4.1. Команды рассматриваются с учетом состояния, в котором они допустимы.
5.1. Команды клиента – любое состояние
Следующие команды могут использоваться в любом состоянии: CAPABILITY, NOOP и LOGOUT.
5.1.1. Команда CAPABILITY
Аргументы: отсутствуют.
Отклики: Необходим немаркированный отклик: CAPABILITY.
Результат: OK – успешное завершение команды;
BAD – команда неизвестна или неверный аргумент
Команда CAPABILITY запрашивает перечень возможностей, поддерживаемых сервером. Сервер должен послать один немаркированный отклик CAPABILITY с "IMAP 4.1" в списке возможностей, прежде чем отправлять маркированный отклик OK. Этот список не зависит от состояния соединения или пользователя. Следовательно, нет необходимости направлять команду CAPABILITY более одного раза на соединение. Название возможности, которая начинается с "AUTH=" указывает, что сервер поддерживает определенный механизм аутентификации. Все такие имена по определению являются частью данной спецификации. Например, аутентификационные возможности для экспериментального аутентификатора "blurdybloop" могут быть описаны как "AUTH=XBLURDYBLOOP", а не "XAUTH=BLURDYBLOOP" или "XAUTH=XBLURDYBLOOP".
Другие имена возможностей относятся к расширениям, новым версиям или коррекциям данной спецификации.
Пример: C: abcd CAPABILITY
S: * CAPABILITY IMAP 4.1 AUTH=KERBEROS_V4
S: abcd OK CAPABILITY completed
5.1.2. Команда NOOP
Аргументы: отсутствуют.
Отклики: никакого специального отклика на эту команду не требуется.
Результат: OK – команда успешно завершена;
BAD – команда неизвестна или неверен аргумент;
Команда NOOP ничего не делает и всегда успешно завершается.
Так как любая команда может прислать немаркированные данные об изменении состояния, команда NOOP может использоваться, как периодический запрос нового сообщения или информации об изменении статуса в периоды неактивности. Команда NOOP может также использоваться для сброса таймера прерывания сессии сервером из-за отсутствия активности.
Пример: C: a002 NOOP
S: a002 OK NOOP completed
. . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed
5.1.3. Команда LOGOUT
Аргументы: отсутствуют.
Отклики: необходим немаркированный отклик BYE.
Результат: OK – прерывание сессии завершено;
BAD – неизвестная команда или неверный аргумент.
Команда LOGOUT информирует сервер о том, что клиент прерывает соединение. Сервер должен послать немаркированный отклик BYE, прежде чем отсылать маркированный отклик OK, после чего завершить разрыв соединения.
Пример: C: A023 LOGOUT
S: * BYE IMAP 4.1 Server logging out
S: A023 OK LOGOUT completed
(Сервер и клиент разорвали соединение)
5.2. Команды клиента – в состоянии без аутентификации
В состоянии без аутентификации, команды AUTHENTICATE или LOGIN организуют аутентификацию и переводят систему в состояние с аутентификацией. Об аутентификации в IMAP можно прочесть в документе RFC-1731. Команда AUTHENTICATE предоставляет общий механизм для целого ряда методов аутентификации, среди которых команда LOGIN используется для традиционного ввода имени и пароля в текстовом виде.
Различные реализации сервера могут позволять доступ без аутентификации к некоторым почтовым ящикам. По договоренности в этом случае команда LOGIN предполагает ввод имени "anonymous". Ввод пароля всегда обязателен. Требования на пароль определяются конкретной версией программной реализации.
По завершении аутентификации невозможно вернуться непосредственно в состояние “без аутентификации”. В дополнение к универсальным командам (CAPABILITY, NOOP и LOGOUT), в состоянии “без аутентификации” возможны команды: AUTHENTICATE и LOGIN.
5.2.1. Команда AUTHENTICATE
Аргументы: имя механизма аутентификации.
Отклики: может быть запрошена дополнительная информация.
OK |
Аутентификация завершена, осуществлен переход в состояние ”аутентификация выполнена”; |
NO |
Ошибка аутентификации: неподдерживаемый механизм аутентификации, параметры аутентификации отвергнуты; |
BAD |
Неизвестная команда или неверный аргумент, механизм аутентификации прерван. |
Команда AUTHENTICATE указывает серверу на механизм аутентификации, как это описано в [IMAP-AUTH].
Если сервер поддерживает запрошенный механизм аутентификации, он выполняет обмен согласно аутентификационному протоколу и идентифицирует клиента. Он может также согласовать опционный механизм защиты для последующих протоколов взаимодействия. Если запрошенный механизм аутентификации не поддерживается, сервер должен отвергнуть команду AUTHENTICATE путем посылки маркированного отклика NO.
Протокол аутентификационного обмена состоит из последовательности запросов сервера и соответствующих ответов клиента. Запрос сервера состоит из отклика-запроса продолжения с символом "+", за которым следует строка кодов BASE64. Ответ клиента состоит из строки, содержащей коды BASE64. Если клиент хочет аннулировать аутентификационный обмен, он выдает строку, содержащую только "*". Если сервер получает такой ответ, он должен отклонить команду AUTHENTICATE, послав маркированный отклик BAD.
Механизм защиты обеспечивает целостность и конфиденциальность соединения. Если механизм защиты согласовыван, то в дальнейшем он используется для всех сообщений, проходящих через данное соединение. Механизм защиты начинает действовать сразу после ввода последовательности CRLF, которая завершает аутентификационный обмен для клиента, и прихода CRLF маркированного отклика OK сервера. Раз механизм защиты вступил в силу, поток октетов команд и откликов заносится в буферы шифрованного текста. Каждый буфер передается через соединение в виде потока октетов, который начинается с четырех октетов, содержащих длину последующих данных. Максимальный размер буфера для текста-шифра определяется выбранным механизмом защиты.
Аутентификационные механизмы являются опционными. Механизмы защиты также опционны; аутентификационный механизм может реализоваться в отсутствии какого-либо механизма защиты. Если команда AUTHENTICATE не прошла и получен отклик NO, клиент может совершить повторную попытку, послав еще одну команду AUTHENTICATE, или может попытаться выполнить аутентификацию с помощью команды LOGIN. Другими словами, клиент может затребовать тип аутентификации в порядке понижения уровня предпочтения, команда LOGIN используется как последний вариант.
Пример: S: * OK KerberosV4 IMAP4rev1 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful
5.2.2. Команда LOGIN
Аргументы: имя пользователя, пароль.
Отклики: команда не требует какого-либо специального отклика.
Результат: OK - login завершено, система в состоянии с аутентификацией;
NO - login не прошла: имя пользователя или пароль отвергнуты;
BAD – команда неизвестна или неверный аргумент.
Команда LOGIN идентифицирует клиента серверу и передает пароль пользователя открытым текстом.
Пример: C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed
5.3. Команды клиента в состоянии “аутентификация осуществлена”
В состоянии “аутентификация осуществлена” разрешены команды манипуляции почтовыми ящиками, как объектами-атомами. Команды SELECT и EXAMINE реализует выбор почтового ящика и переход в состояние “выбрано” .
В добавление к стандартным командам (CAPABILITY, NOOP и LOGOUT), в состоянии "аутентификация осуществлена" допустимы следующие команды: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND.
5.3.1. Команда SELECT
Аргументы: имя почтового ящика.
Отклики: необходимы немаркированные отклики: FLAGS, EXISTS, RECENT;
опционны немаркированные отклики OK: UNSEEN, PERMANENTFLAGS.
Результат: OK – процедура выбора закончена, система находится в состоянии "выбрано";
NO – выбор неудачен: нет такого ящика, доступ к почтовому ящику невозможен;
BAD – команда неизвестна или неверен аргумент.
Команда SELECT осуществляет выбор почтового ящика, так чтобы обеспечить доступ к сообщениям, находящимся там. Прежде чем присылать клиенту OK, сервер должен послать клиенту следующие немаркированные данные:
FLAGS - флаги, определенные для почтового ящика.
EXISTS Число сообщений в почтовом ящике.
RECENT Число сообщений с набором флагов \Recent.
OK [UIDVALIDITY ] Уникальный идентификатор корректности.
Сервер должен также послать “невидимый” код отклика внутри немаркированного сообщения OK, который представляет собой порядковый номер первого невидимого сообщения в почтовом ящике.
Если клиент не может изменить состояние одного или нескольких флагов, перечисленных в немаркированном отклике FLAGS, сервер должен в немаркированном отклике OK послать код PERMANENTFLAGS, перечислив флаги, которые клиент может изменить.
Единовременно для одного соединения может быть выбран только один почтовый ящик. Одновременный доступ к нескольким почтовым ящикам требует установления соответствующего числа соединений. Команда SELECT автоматически аннулирует выбор почтового ящика при повторной попытке его выбора. Следовательно, если почтовый ящик был выбран, а команда SELECT не прошла, предшествующий выбор ящика аннулирован. Если клиенту разрешено модифицировать почтовый ящик, сервер должен снабжать маркированный текст отклика OK префиксом "[READ-WRITE]".
Если клиенту не позволено модифицировать почтовый ящик, но разрешен доступ для чтения, почтовый ящик выбирается в режиме “только для чтения” и сервер должен перед посылкой текста передать маркированный отклик OK в ответ на команду SELECT с кодом отклика "[READ-ONLY]". Доступ “только для чтения” тем не менее, отличается от команды EXAMINE, при нем некоторые почтовые ящики позволяют изменять постоянное состояние некоторых флагов пользователя. Сетевые новости из файла .newsrc являются примером того, как некоторые состояния могут изменяться для почтовых ящиков типа “только для чтения”.
Пример: C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed
5.3.2. Команда EXAMINE
Аргументы: имя почтового ящика.
Отклики: необходимы немаркированные отклики: FLAGS, EXISTS, RECENT;
опционны немаркированные отклики OK: UNSEEN, PERMANENTFLAGS.
Результат: |
OK |
Осмотр закончен, система в состоянии “выбор сделан" ; |
| NO | Осмотр не прошел, система в состоянии “аутентификация выполнена”; нет такого почтового ящика; доступ к почтовому ящику невозможен; | |
| BAD | Команда неизвестна или неверен аргумент. |
Пример: C: A932 EXAMINE blurdybloop
S: * 17 EXISTS
S: * 2 RECENT
S: * OK [UNSEEN 8] Message 8 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: A932 OK [READ-ONLY] EXAMINE completed
5.3.3. Команда CREATE
Аргументы: имя почтового ящика.
Отклики: на эту команду не посылается каких-либо откликов.
| Результат | OK | команда выполнена; |
| NO | команда не выполнена: почтовый ящик с таким именем не может быть создан; | |
| BAD | команда неизвестна или неверен аргумент. |
Если имя почтового ящика имеет суффикс с символом сепаратора иерархии сервера (в соответствии с тем, что получено при выполнении команды LIST), то это является декларацией клиента о намерении создать почтовый ящик с именем в рамках указанной иерархии. Реализации сервера, которые не требуют этой декларации, должны ее игнорировать.
Если символ-сепаратор иерархии сервера появляется где-либо еще в имени, сервер должен создать любые имена более высокого уровня иерархии, которые необходимы для успешного завершения выполнения команды CREATE.
Другими словами, попытка создания "foo/bar/zap" на сервере, для которого символ "/" является иерархическим сепаратором, должна привести к созданию foo/ и foo/bar/, если они до этого не существовали.
Если новый почтовый ящик создан с именем стертого почтового ящика, то его идентификатор должен быть больше, использованного его предшественником, если только новая версия ящика не имеет другого значения UID.
Пример: C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed
Замечание: интерпретация этого примера зависит от того, является ли символ "/" иерархическим сепаратором. Если "/" иерархический сепаратор, создается новый иерархический уровень с "owatagusiam" с новым членом иерархии этого уровня "blurdybloop". В противном случае создаются два почтовых ящика на одном и том же уровне иерархии.
5.3.4. Команда DELETE
Аргументы: имя почтового ящика.
Отклики: команда не требует каких-либо откликов.
Результат: OK – команда завершена;
NO – ошибка при выполнении команды: не удается стереть ящик с этим именем;
BAD - команда неизвестна или неверен аргумент.
Команда DELETE навечно удаляет почтовый ящик с указанным именем. При этом присылается маркированный отклик OK только в том случае, когда ящик уничтожен. Ошибкой считается попытка стереть INBOX или ящик с несуществующим именем.
Команда DELETE не должна удалять ящики с более низкой иерархией, чем текущая. Например, если почтовый ящик "foo" имеет иерархическую структуру "foo.bar" (предполагается, что "." является иерархическим сепаратором), удаление "foo" не должно удалять "foo.bar". Считается ошибкой попытка удаления имени, которому соответствуют нижележащие иерархические уровни, имеющие атрибут \Noselect.
Разрешено удалять имена, которым соответствуют нижележащие иерархические уровни, но не имеющие атрибута имени \Noselect. В этом случае все сообщения из этого почтового ящика также будут удалены, а имя получит атрибут \Noselect.
Значение наибольшего используемого уникального идентификатора удаленных почтовых ящиков должно сохраняться, так чтобы новые созданные ящики с тем же именем не использовали идентификаторы своих предшественников, если только новый ящик не имеет другое значение UID.
Примеры: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 DELETE blurdybloop
S: A683 OK DELETE completed
C: A684 DELETE foo
S: A684 NO Name "foo" has inferior hierarchical names
C: A685 DELETE foo/bar
S: A685 OK DELETE Completed
C: A686 LIST "" *
S: * LIST (\Noselect) "/" foo
S: A686 OK LIST completed
C: A687 DELETE foo
S: A687 OK DELETE Completed
C: A82 LIST "" *
S: * LIST () "." blurdybloop
S: * LIST () "." foo
S: * LIST () "." foo.bar
S: A82 OK LIST completed
C: A83 DELETE blurdybloop
S: A83 OK DELETE completed
C: A84 DELETE foo
S: A84 OK DELETE Completed
C: A85 LIST "" *
S: * LIST () "." foo.bar
S: A85 OK LIST completed
C: A86 LIST "" %
S: * LIST (\Noselect) "." foo
S: A86 OK LIST completed
5.3.5. Команда RENAME
Аргументы: имя существующего почтового ящика, имя нового почтового ящика.
Отклики: эта команда не требует каких-либо специфических откликов.
| Результат: | OK | переименование успешно осуществилось; |
| NO | переименование не прошло: не удалось переименовать ящик с данным именем, не удалось присвоить новое имя; | |
| BAD | команда неизвестна или неверен аргумент. |
Если ящик содержит в себе иерархическую структуру, имена этой структуры не должны меняться. Например, переименование "foo" в "zap" переименует "foo/bar" (предполагая, что "/" является иерархическим разделителем) в "zap/bar".
Значение наибольшего использованного уникального идентификатора имени старого почтового ящика должно быть сохранено, так чтобы новый создаваемый с тем же именем почтовый ящик не использовал идентификатора своего предшественника, если только он не имеет другого значения UID.
Переименование INBOX разрешено, но имеет свою специфику. Оно перемещает все сообщения в почтовый ящик с новым именем, оставляя INBOX пустым. Если реализация сервера поддерживает иерархические системы имен INBOX, это никак не сказывается на переименовании INBOX.
Примеры: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 RENAME blurdybloop sarasoop
S: A683 OK RENAME completed
C: A684 RENAME foo zowie
S: A684 OK RENAME Completed
C: A685 LIST "" *
S: * LIST () "/" sarasoop
S: * LIST (\Noselect) "/" zowie
S: * LIST () "/" zowie/bar
S: A685 OK LIST completed
C: Z432 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: Z432 OK LIST completed
C: Z433 RENAME INBOX old-mail
S: Z433 OK RENAME completed
C: Z434 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: * LIST () "." old-mail
S: Z434 OK LIST completed
5.3.6. Команда SUBSCRIBE
Аргументы: имя почтового ящика.
Отклики: эта команда не требует каких-либо специфических откликов.
Результат: OK – процедура подписки завершена;
NO - подписка не прошла: подписка для данного имени невозможна;
BAD - команда неизвестна или неверен аргумент.
Команда SUBSCRIBE добавляет специфицированное имя почтового ящика к списку “активных” или "подписных" ящиков сервера, как это реализуется командой LSUB. Эта команда присылает маркированный отклик OK только в случае успешного осуществления подписки.
Сервер может проверить аргумент команды SUBSCRIBE, чтобы проконтролировать его корректность для данного почтового ящика.
Однако он не должен в одностороннем порядке удалять существующее имя почтового ящика из подписного листа, даже если ящика с таким именем более не существует.
Замечание: это требование возникает потому, что некоторые серверы могут удалить почтовый ящик с известным именем, например, "system-alerts") после того как срок годности его содержимого истек с тем, чтобы создать его вновь при появлении новых сообщений.
Пример: C: A002 SUBSCRIBE #news.comp.mail.mime
S: A002 OK SUBSCRIBE completed
5.3.7. Команда UNSUBSCRIBE
Аргументы: имя почтового ящика.
Отклики: эта команда не требует каких-либо специфических откликов.
Результат: OK – ликвидация подписки прошла успешно;
NO – ликвидация подписки не прошла: это невозможно для данного имени;
BAD - команда неизвестна или неверен аргумент.
Команда UNSUBSCRIBE удаляет специфицированный почтовый ящик из списка "активных" или "подписных" почтовых ящиков данного сервера, как это определяется командой LSUB. Эта команда возвращает маркированный отклик OK только в случае, если ликвидация подписки прошла успешно.
Пример: C: A002 UNSUBSCRIBE #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE completed
5.3.8. Команда LIST
Аргументы: имя,
имя почтового ящика может содержать символы подмены (wildcard).
Отклики: немаркированные отклики LIST.
| Результат: | OK | команда list выполнена; |
| NO | команда не прошла: не возможно выполнение list для данного образца или имени; | |
| BAD | команда неизвестна или неверен аргумент. |
Команда LIST должна возвращать данные быстро без существенных задержек. Например, она не должна тратить время на выяснение статуса (\Marked или \Unmarked) или на выполнение другой трудоемкой обработки, ведь если каждое имя требует одной секунды, то обработка списка из 1200 имен займет 20 минут.
Аргумент, содержащий пустую строку образца имени (""), указывает, что имя почтового ящика интерпретируется также, как это делает команда SELECT.
Присланные имена почтовых ящиков должны соответствовать полученному шаблону имени. Непустой аргумент является шаблоном имени почтового ящика или уровеня иерархии и указывает на контекст, в котором интерпретируется имя. Пустой аргумент имени ("") представляет собой специальный запрос, требующий присылки иерархического разделителя и корневого имени. Значение, возвращаемое в качестве корневого имени, может быть нулем, если шаблону не соответствует никакая иерархия. Иерархический разделитель присылается во всех случаях. Это позволяет клиенту получить иерархический разделитель даже в случае, когда нет почтовых ящиков, соответствующих данному имени.
Шаблон и имя почтового ящика интерпретируются по-разному в зависимости от реализации. В каноническом варианте анализ происходит слева направо.
Любая часть аргумента шаблона, которая включена в интерпретированную форму, должна предшествовать интерпретированной форме. Она должна иметь тот же формат, что и аргумент шаблона имени. Это правило позволяет клиенту определить, соответствует ли присланное имя почтового ящика контексту шаблона. Без этого правила, клиент должен был бы знать семантику имен сервера.
Ниже приведены некоторые примеры того, как могут интерпретироваться образцы и имена почтовых ящиков на серверах базирующихся на UNIX:
| Шаблон | Имя почтового ящика | Интерпретация |
| ~smith/Mail/ | foo.* | ~smith/Mail/foo.* |
| Archive/ | % | archive/% |
| #news. | comp.mail.* | #news.comp.mail.* |
| ~smith/Mail/ | /usr/doc/foo | /usr/doc/foo |
| archive/ | ~fred/Mail/* | ~fred/Mail/* |
Символ "*" представляет собой подмену (wildcard), и соответствует нулю или более символов в данной позиции. Символ "%" подобен "*", но он не соответствует иерархическому разделителю.
Если символ "%" является последним символом имени почтового ящика, то в отклике будут присланы и соответствующие уровни иерархии. Если эти уровни не являются почтовыми ящиками, которые можно выбрать, то их имена снабжаются атрибутом \Noselect. Реализациям сервера таким образом позволено спрятать некоторые почтовые ящики, имена которых могли бы быть раскрыты с использованием шаблонов с символами подмены (wildcard). Например, сервер на основе UNIX может ограничить интерпретацию "*" так, что начальный символ "/" будет приводить к несоответствию имени шаблону.
Специальное имя INBOX включается в выдачу команды LIST, если INBOX поддерживается данным сервером для данного пользователя и, если строка "INBOX", напечатанная прописными буквами, соответствует интерпретированному шаблону.
Пример: C: A101 LIST "" ""
S: * LIST (\Noselect) "/" ""
S: A101 OK LIST Completed
C: A102 LIST #news.comp.mail.misc ""
S: * LIST (\Noselect) "." #news.
S: A102 OK LIST Completed
C: A103 LIST /usr/staff/jones ""
S: * LIST (\Noselect) "/" /
S: A103 OK LIST Completed
C: A202 LIST ~/Mail/ %
S: * LIST (\Noselect) "/" ~/Mail/foo
S: * LIST () "/" ~/Mail/meetings
S: A202 OK LIST completed
5.3.9. Команда LSUB
Аргументы: имя-шаблон,
имя почтового ящика может содержать символы подмены (wildcards).
Отклики: немаркированный отклик: LSUB
| Результат: | OK | команда успешно исполнена; |
| NO | команда не прошла: не возможна выдача списка для предлагаемого шаблона или имени; | |
| BAD | команда неизвестна или неверен аргумент. |
Сервер может проверить имена из подписного листа с тем, чтобы проверить, существуют ли они еще.
Если имени не существует, оно должно быть помечено в отклике LSUB атрибутом \Noselect. Сервер не должен по своему усмотрению удалять имена почтовых ящиков из подписного листа даже, если такого ящика более не существует.
Пример: C: A002 LSUB "#news." "comp.mail.*"
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
5.3.10. Команда STATUS
Аргументы: имя почтового ящика, статусная информация имен.
Отклики: немаркированные отклики: STATUS.
Результат: OK – команда успешно выполнена;
NO – команда не прошла: нет статусной информации для данного имени;
BAD - команда неизвестна или неверен аргумент.
Команда STATUS запрашивает статусные данные для указанного почтового ящика. Она не изменяет выбор почтового ящика и не вносит каких-либо изменений в состояние сообщений для запрошенного ящика (в частности команда STATUS не должна вызывать потерю флага \Recent).
Команда STATUS предоставляет альтернативу открытию дополнительного IMAP 4.1 соединения и реализует команду EXAMINE для запрашиваемого почтового ящика, не изменяя выбора, выполненного при первичном соединении.
В отличии от команды LIST, команда STATUS не гарантирует быстрого отклика. В некоторых реализациях сервер обязан открыть почтовый ящик в режиме “только чтение”, чтобы получить нужные статусные данные. Кроме того, команда STATUS не допускает символов подмены в шаблоне имени. В настоящее время определены следующие статусные данные, которые могут быть запрошены:
| MESSAGES | Число сообщений в почтовом ящике |
| RECENT | Число сообщений с установленным флагом \Recent |
| UIDNEXT | Следующее значение, которое будет предписано новому сообщению в почтовом ящике. Гарантируется, что это значение не изменится, если только в ящик не будет положено новое сообщение. UID будет изменен при укладке нового сообщения, даже если оно после этого стерто. |
| UIDVALIDITY | Уникальный валидатор почтового ящика |
| UNSEEN | Число сообщений, не имеющих установленного флага \Seen |
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
S: A042 OK STATUS completed
5.3.11. Команда APPEND
Аргументы: имя почтового ящика,
опционно – флаг списка со скобками,
опционно – строка даты и времени,
литерал сообщения
Отклики: команда не требует какого-либо специального отклика
| Результат: | OK | команда успешно исполнена |
| NO | команда не прошла: добавление в почтовый ящик не удалось, ошибка во флагах или дате/времени, или в тексте сообщения | |
| BAD | команда неизвестна или неверен аргумент |
Если специфицировано date_time, в результирующем сообщении должна быть установлена внутренняя дата, в противном случае, внутренняя дата и время результирующего сообщения будут установлены по умолчанию равными текущим значениям. Если команда append по какой-то причине не прошла, почтовый ящик должен быть возвращен в состояние, которое он имел до команды APPEND.
Если почтовый ящик места назначения не существует, сервер должен сообщить об ошибке, а не должен автоматически создавать новый почтовый ящик. Если не ясно, может или нет быть создан почтовый ящик, сервер должен послать код отклика "[TRYCREATE]" в качестве префикса текста маркированного отклика NO. Это указывает клиенту на возможность попытки исполнения команды CREATE, после чего, в случае успеха, повторить команду APPEND.
Если в настоящее время почтовый ящик и выбран, то немедленно должны начаться почтовые операции. Сервер должен уведомить клиента об этом, послав немаркированный отклик EXISTS.
Если сервер не делает этого, клиент после одной или более команд APPEND может выдать команду NOOP (или при неудаче команду CHECK).
Пример: C: A003 APPEND saved-messages (\Seen) {310}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id:
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK APPEND completed
Замечание: команда APPEND не используется для доставки сообщений, так как она не содержит в себе механизма передачи служебной информации [SMTP].
5.4. Команды клиента в состоянии “выбор сделан”
В состоянии “выбор сделан”, разрешены команды, которые манипулируют сообщениями в почтовом ящике. Помимо универсальных команд (CAPABILITY, NOOP и LOGOUT), а также команд режима аутентификации (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND), в данном режиме доступны следующие команды: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY и UID.
5.4.1. Команда CHECK
Аргументы: отсутствуют.
Отклики: команда не требует какого-либо специального отклика;
Результат: OK – проверка завершена;
BAD - команда неизвестна или неверен аргумент.
Команда CHECK осуществляет проверку выбранного почтового ящика. Проверка относится к любым характеристикам, зависящим от реализации (например, выявление положения почтового ящика в памяти сервера и на диске). Если сервер не поддерживает таких возможностей, команда эквивалентна NOOP.
Не существует гарантии, что в результате CHECK будет прислан немаркированный отклик. Для проверки поступления новой почты следует использовать команду NOOP, а не CHECK.
Пример: C: FXXZ CHECK
S: FXXZ OK CHECK Completed
5.4.2. Команда CLOSE
Аргументы: отсутствуют.
Отклики: команда не требует какого-либо специального отклика.
Результат: OK – команда выполнена, система в состоянии “аутентификация выполнена”;
NO – команда не прошла, никакого ящика не выбрано;
BAD - команда неизвестна или неверен аргумент.
Команда CLOSE навечно удаляет из выбранного почтового ящика все сообщения, помеченные флагом \Deleted, и возвращает систему в состояние “аутентификация выполнена”. Никакого немаркированного отклика EXPUNGE не посылается.
Никаких сообщений не удаляется и никаких флагов ошибки не возвращается, если почтовый ящик был выбран командой EXAMINE или находился в режиме “только для чтения”.
Даже если почтовый ящик выбран, команды SELECT, EXAMINE или LOGOUT могут быть использованы без предварительного исполнения команды CLOSE. Команды SELECT, EXAMINE и LOGOUT безоговорочно закрывают выбранный в данный момент почтовый ящик без удаления сообщений. Однако когда удалено много сообщений, последовательность CLOSE-LOGOUT или CLOSE-SELECT значительно быстрее, чем EXPUNGE-LOGOUT или EXPUNGE-SELECT, так как здесь не посылается никаких немаркированных откликов EXPUNGE (которые клиент вероятно проигнорирует).
Пример: C: A341 CLOSE
S: A341 OK CLOSE completed
5.4.3. Команда EXPUNGE
Аргументы: отсутствуют.
Отклики: немаркированные отклики: EXPUNGE.
Результат: OK – команда успешно завершена;
NO – команда не прошла: стирание не выполнено (например, запрещено);
BAD - команда неизвестна или неверен аргумент.
Команда EXPUNGE навечно удаляет из выбранного почтового ящика все сообщения, которые помечены флагами \Deleted. Прежде чем выдать клиенту сигнал OK, посылается немаркированный отклик EXPUNGE для каждого из удаляемых сообщений.
Пример: C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed
Замечание: в этом примере, сообщения 3, 4, 7 и 11 имеют установленный флаг \Deleted. Следует учитывать, что после каждого удаления сообщения перенумеруются.
5.4.4. Команда SEARCH
Аргументы: опционны, [CHARSET]-спецификация.
Критерии поиска (один или более).
Отклики: необходим немаркированный отклик: SEARCH.
Результат: OK – поиск завершен;
NO – ошибка: поиск для данного набора символов или критериев не возможен;
BAD - команда неизвестна или неверен аргумент
Команда SEARCH ищет почтовый ящик, который отвечает выбранным критериям отбора. Критерий отбора состоит из одного или более ключей поиска. Немаркированный отклик SEARCH от сервера содержит список номеров сообщений, которые соответствуют критериям отбора.
Когда специфицировано несколько ключей, результатом является (функция AND) совокупность всех сообщений, отвечающим заданным критериям. Например, критерий DELETED FROM "SMITH" SINCE 1-Feb-1994 относится ко всем стертым сообщениям от Смита, которые были положены в почтовый ящик после 1-го февраля 1994. (например, для объединения этих ключей с помощью функций OR и NOT).
Опционная спецификация [CHARSET] состоит из слова "CHARSET", за которым следует зарегистрированное наименование символьного набора [CHARSET]. Он включает в себя [CHARSET] строк, которые используются в качестве критерия отбора. Транспортное кодирование содержимого [MIME-IMB] и строки [MIME-HDRS] в [RFC-822]/[MIME-IMB] заголовках, должны декодироваться перед сравнением текста в представлении [CHARSET], отличном от US-ASCII. US-ASCII должно поддерживаться всегда, но могут использоваться и другие символьные наборы. Если сервер не поддерживает специфицированный набор символов [CHARSET], он должен вернуть маркированный отклик NO (но не BAD).
Для всех ключей поиска, которые используют строки, сообщение соответствует ключу, если строка является частью строки поля в сообщении. Соответствие не должно зависеть от использования строчных или прописных символов. Стандартными ключами поиска являются следующие слова и выражения.
| Сообщения с номерами, соответствующими специфицированному набору номеров | |
| ALL | Все сообщения в почтовом ящике. Ключ отбора по умолчанию для применения команд AND |
| ANSWERED | Сообщения с установленным флагом \Answered. |
| BCC | Сообщения, которые содержат специфицированную строку в поле BCC структуры заголовка сообщения. |
| BEFORE | Сообщения, чьи внутренние даты раньше указанной. |
| BODY | Сообщения, которые содержат специфицированную строку в теле сообщения. |
| CC | Сообщения, которые содержат специфицированную строку в CC поле заголовка. |
| DELETED | Сообщения с установленным флагом \Deleted. |
| DRAFT | Сообщения с установленным флагом \Draft. |
| FLAGGED | Сообщения c установленным флагом \Flagged. |
| FROM | Сообщения, которые содержат специфицированную строку в поле FROM заголовка. |
| HEADER | Сообщения, которые содержат заголовок со специфицированным именем поля (в соответствии с [RFC-822]) и специфицированную строку в теле данного поля. |
| KEYWORD | Сообщения со специфицированным ключевыми словами. |
| LARGER | Сообщения с размером [RFC-822] больше чем специфицированное число октетов. |
| NEW | Сообщения, которые имеют установленный флаг \Recent, но не имеют флага \Seen. Это функционально эквивалентно "(RECENT UNSEEN)". |
| NOT | Сообщения, которые не содержат специфицированного ключевого слова. |
| OLD | Сообщения, которые не имеют флага \Recent. "NOT RECENT" (противоположно "NOT NEW"). |
| ON | Сообщения, чья внутренняя дата соответствует специфицированному значению даты. |
| OR | Сообщения, которые соответствуют любому из ключевых слов поиска. |
| RECENT | Сообщения, которые имеют установленный флаг \Recent. |
| SEEN | Сообщения, которые имеют установленный флаг \Seen. |
| SENTBEFORE | Сообщения, чье содержимое заголовка, соответствует дате ранее специфицированного значения [RFC-822]. |
| SENTON | Сообщения, чье содержимое заголовка, соответствует специфицированной дате [RFC-822] |
| SENTSINCE | Сообщения, чье содержимое заголовка, соответствует [RFC-822]: специфицированному значению даты или позже. |
| SINCE | Сообщения, чья внутренняя дата соответствует или позже специфицированного значения. |
| SMALLER | Сообщения с размером [RFC-822] меньше чем специфицированное число октетов. |
| SUBJECT | Сообщения, которое содержит специфицированную строку в поле SUBJECT заголовка. |
| TEXT | Сообщения, которые содержат специфицированную строку в заголовке или теле сообщения |
| TO | Сообщения, которые содержат специфицированную строку в поле заголовка TO. |
| UID | Сообщения с уникальными идентификаторами, соответствующими заданному значению идентификатора. |
| UNANSWERED | Сообщения, которые не имеют флага \Answered. |
| UNDELETED | Сообщения, которые не имеют флага \Deleted. |
| UNDRAFT | Сообщения, которые не имеют флага \Draft. |
| UNFLAGGED | Сообщения, которые не имеют флага \Flagged. |
| UNKEYWORD | Сообщения, которые не содержат заданных ключевых слов. |
| UNSEEN | Сообщения, которые не имеют флага \Seen. |
Пример: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S: * SEARCH 2 84 882
S: A282 OK SEARCH completed
5.4.5. Команда FETCH
Аргументы: набор сообщений,
имена информационных сообщений.
Отклики: немаркированные отклики: FETCH
Результат: OK – операция успешно завершена;
NO – команда не прошла: не удалось доставить эти данные;
BAD - команда неизвестна или неверен аргумент.
Команда FETCH извлекает данные, соответствующие сообщению в почтовом ящике. В качестве доставляемых данных может выступать отдельный атом или список элементов, помещенных в скобками. В настоящее время определены следующие типы данных, которые могут быть доставлены:
ALL Эквивалентно: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
BODY Нерасширяемая форма BODYSTRUCTURE.
BODY[]>
Текст определенной части тела сообщения. Спецификация секции представляет собой нуль или более спецификаторов, разделенных точками. Спецификатором части является либо число, либо одно из имен:
HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME и TEXT. Пустая спецификация относится ко всему сообщению, включая заголовок.
Каждое сообщение имеет номер, по крайней мере, одной части.
Сообщения не-[MIME-IMB] и несоставные сообщения [MIME-IMB] без инкапсуляции имеют только часть 1.
Частям составных сообщений присваиваются последовательные номера в порядке появления. Если конкретная часть является составным сообщением, то его части должны быть выделены точкой, за которой следует номер части.
Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT и TEXT являются базовыми. Перед ними могут размещаться один или более числовых спецификаторов частей сообщения, которые указывают на принадлежность типу MESSAGE/RFC822. Перед спецификатором части MIME должны размещаться один или более числовых спецификаторов. Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT относятся к заголовку сообщения [RFC-822] или инкапсулированному сообщению [MIME-IMT] MESSAGE/RFC822. За HEADER.FIELDS и HEADER.FIELDS.NOT следует список имен полей (как это определено в [RFC-822]).
Субнабор, возвращаемый HEADER.FIELDS, содержит только те поля заголовка, имена которых соответствуют одному из имен списка. Аналогично, субнабор, возвращаемый HEADER.FIELDS.NOT, содержит только поля заголовка с несоответствующими именами полей. Соответствие является точным, но нечувствительным к использованию строчных и прописных букв. Во всех случаях, вставляется разграничивающая пустая строка между заголовком и телом сообщения.
Спецификатор MIME части относится к заголовку [MIME-IMB] этой части. Спецификатор текстовой части относится к телу сообщения, без заголовка [RFC-822]. Ниже приведен пример составного сообщения с некоторыми спецификаторами его частей:
HEADER ([RFC-822] заголовок сообщения)
TEXT MULTIPART/MIXED
1 TEXT/PLAIN
2 APPLICATION/OCTET-STREAM
3 MESSAGE/RFC822
3.HEADER ([RFC-822] заголовок сообщения)
3.TEXT ([RFC-822] текстовое тело сообщения)
3.1 TEXT/PLAIN
3.2 APPLICATION/OCTET-STREAM
4 MULTIPART/MIXED
4.1 IMAGE/GIF
4.1.MIME ([MIME-IMB] заголовок для IMAGE/GIF)
4.2 MESSAGE/RFC822
4.2.HEADER ([RFC-822] заголовок сообщения)
4.2.TEXT ([RFC-822] текстовое тело сообщения)
4.2.1 TEXT/PLAIN
4.2.2 MULTIPART/ALTERNATIVE
4.2.2.1 TEXT/PLAIN
4.2.2.2 TEXT/RICHTEXT
Имеется возможность доставить субстроку определенного текста. Это делается путем присоединения к спецификатору части открытой угловой скобки (" При любой частичной доставке, при которой производится попытка чтения за пределами текста, фрагмент соответствующим образом обрезается.
Замечание: это означает, что запрос BODY[] сообщения длиной 1500 октетов пришлет BODY[] с литералом размера 1500, а не BODY[].
| BODY.PEEK[] > | Альтернативная форма BODY[], которая не устанавливает флаг \Seen. |
| BODYSTRUCTURE | Структура тела сообщения [MIME-IMB]. Она вычисляется сервером путем разбора полей заголовка [MIME-IMB] [RFC-822] и заголовков [MIME-IMB]. |
| ENVELOPE | Структура заголовка сообщения. Она вычисляется сервером в результате разбора заголовка [RFC-822] на части, присваивая им значения по умолчания, если это необходимо. |
| FAST | Макро эквивалент (FLAGS INTERNALDATE RFC822.SIZE) |
| FLAGS | Флаги, присвоенные сообщению. |
| FULL | Макро эквивалент (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY) |
| INTERNALDATE | Внутренняя дата сообщения. |
| RFC822 | Функционально эквивалентно BODY[], отличается по синтаксису результирующих немаркированных данных FETCH (возвращается RFC822). |
| RFC822.HEADER | Функционально эквивалентно BODY.PEEK[HEADER], отличается по синтаксису результирующих немаркированных данных FETCH (возвращает данные в формате RFC822.HEADER). |
| RFC822.SIZE | Размер сообщения [RFC-822]. |
| RFC822.TEXT | Функционально эквивалентно BODY[TEXT], отличается по синтаксису результирующих немаркированных данных FETCH (возвращается RFC822.TEXT). |
| UID | Уникальный идентификатор сообщения. |
S: * 2 FETCH ....
S: * 3 FETCH ....
S: * 4 FETCH ....
S: A654 OK FETCH completed
5.4.6. Команда STORE
Аргументы: набор сообщений,
имя элемента сообщения,
значение элемента сообщения.
Отклики: немаркированные отклики: FETCH.
Результат: OK – операция успешно завершена;
NO – команда не прошла: данные не могут быть запомнены;
BAD - команда неизвестна или неверен аргумент.
Команда STORE заносит данные в почтовый ящик. В норме команда STORE возвращает обновленную версию данных с немаркированным откликом FETCH. ".SILENT" в имени элемента данных блокирует немаркированный отклик FETCH, и сервер должен предполагать, что клиент определил обновленное значение сам или ему обновленное значение не нужно.
Замечание: вне зависимости от того используется или нет суффикс ".SILENT", сервер должен послать немаркированный отклик FETCH, если внешние причины вызвали изменение флагов сообщения.
В настоящее время определены следующие элементы данных:
| FLAGS | Заменить флаги для сообщения, приведенного в аргументе. Новое значение флагов присылается, как если бы выполнялась команда FETCH для этих флагов. |
| FLAGS.SILENT | Эквивалентно FLAGS, но без возвращения нового значения. |
| +FLAGS | Добавить аргумент к флагам сообщения. Новое значение флагов возвращается, как при исполнении команды FETCH. |
| +FLAGS.SILENT | Эквивалентно +FLAGS, но без возвращения нового значения. |
| -FLAGS | Удаляет аргумент из флагов сообщения. Новое значение флагов возвращается, как при исполнении команды FETCH. |
| -FLAGS.SILENT | Эквивалентно -FLAGS, но без возвращения нового значения. |
S: * 2 FETCH FLAGS (\Deleted \Seen)
S: * 3 FETCH FLAGS (\Deleted)
S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)
S: A003 OK STORE completed
5.4.7. Команда COPY
Аргументы: набор сообщений,
имя почтового ящика.
Отклики: команда не требует какого-либо специального отклика.
| Результат: | OK | команда успешно завершена; |
| NO | команда не прошла: не могут быть скопированы эти сообщения вообще или в данный почтовый ящик; | |
| BAD | команда неизвестна или неверен аргумент. |
Флаги и внутренняя дата сообщения должны быть сохранены в копии.
Если указанный почтовый ящик отсутствует, сервер должен прислать сообщение об ошибке. Он не должен автоматически создавать почтовый ящик. Если заведомо не известно, что ящик не может быть создан, сервер должен послать код отклика "[TRYCREATE]" в качестве префикса текста маркированного отклика NO. Это предлагает клиенту возможность исполнить команду CREATE, после чего в случае успешного завершения повторно исполнить COPY.
Если команда COPY не прошла по какой-то причине, сервер должен восстановить почтовый ящик назначения в состояние, которое он имел до выполнения COPY.
Пример: C: A003 COPY 2:4 MEETING
S: A003 OK COPY completed
5.4.8. Команда UID
Аргументы: имя команды,
аргументы команды.
Отклики: немаркированные отклики: FETCH, SEARCH.
Результат: OK – команда UID завершена;
NO – команда UID не прошла;
BAD - команда неизвестна или неверен аргумент.
Команда UID имеет две формы. В первой форме она использует в качестве аргумента имена команд COPY, FETCH или STORE (с их аргументами). Однако числа в списке аргументов в этом случае представляют собой уникальные идентификаторы, а не порядковые номера сообщений.
Во второй форме команда UID использует команду SEARCH с ее аргументами. Интерпретация аргументов та же, что и в случае SEARCH; однако, числа, возвращаемые в отклике на команду UID SEARCH, представляют собой уникальные идентификаторы, а не порядковые номера сообщений. Например, команда UID SEARCH 1:100 UID 443:557 возвратит уникальный идентификатор, соответствующий пересечению порядкового номера сообщения 1:100 и UID 443:557.
Допускаются диапазоны номеров сообщений, однако, нет гарантии, что уникальные идентификаторы образуют монотонную последовательность без пропусков. Не существующие уникальные идентификаторы в списке сообщений игнорируются без генерации сообщения об ошибке.
Число после "*" в немаркированном отклике FETCH всегда является порядковым номером сообщения, а не уникальным идентификатором, даже для отклика на команду UID.
Однако реализации сервера должны безоговорочно включать значения UID в качестве части любого отклика FETCH, вызванного командой UID, вне зависимости от того, был ли UID специфицирован в качестве элемента сообщения для FETCH.
Пример: C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 UID FETCH completed
5.5. Команды клиента – экспериментальные и расширения
5.5.1. Команда X
Аргументы: определяется приложением.
Отклики: определяется приложением.
Результат: OK – команда выполнена;
NO - отказ;
BAD - команда неизвестна или неверен аргумент.
Любая команда с префиксом X является экспериментальной командой. Команды, которые не являются частью этой спецификации стандарта, модификации стандарта или одобренного IESG экспериментального протокола, должны использовать префикс X.
Любой добавленный немаркированный отклик, посланный экспериментальной командой также должен иметь префикс X. Реализации сервера не должны посылать такие немаркированные отклики, если только клиент не запрашивает их посредством какой-либо экспериментальной команды.
Пример: C: a441 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
S: a441 OK CAPABILITY completed
C: A442 XPIG-LATIN
S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
S: A442 OK XPIG-LATIN completed-cay
6. Отклики сервера
Существует три вида откликов сервера: отклики состояния, информация сервера и запрос продолжения команды. Информация, содержащаяся в отклике сервера, идентифицируется словом "Содержимое:".
Клиент должен быть готов воспринять любой отклик в любое время. Отклики состояния могут быть маркированными или нет. Маркированные отклики состояния указывают на результат завершения команды клиента (OK, NO или BAD) и имеют метку, соответствующую команде.
Некоторые отклики состояния и любая информация сервера не маркируются. Немаркированный отклик выделяется символом "*" вместо метки.
Немаркированные отклики состояния отмечают реакцию сервера, они не указывают на завершение выполнения команды (например, предупреждение о предстоящем отключении системы). По историческим причинам немаркированные информационные отклики сервера называются также "незапрашиваемыми данными".
Определенные данные от сервера должны записываться клиентом при получении. Такие данные несут критическую информацию, которая влияет на интерпретацию всех последующих команд и откликов (например, создание или уничтожение сообщений).
Прочие данные сервера следует записывать для последующих ссылок, если клиент не нуждается в записи данных или если запись данных не имеет очевидного смысла (например, отклик SEARCH, когда никакой команды SEARCH не исполняется), такая информация должна игнорироваться.
Немаркированная информация посылается сервером, когда соединение IMAP находится в состоянии "выбрано". В этом состоянии при выполнении команды сервер проверяет наличие новых сообщений в выбранном почтовом ящике. В норме, это часть процедуры выполняется любой командой, следовательно, даже команды NOOP достаточно для проверки наличия новых сообщений. Если обнаружены новые сообщения, сервер посылает немаркированные отклики EXISTS и RECENT, отражающие новые размеры почтового ящика. Реализации сервера, которые предлагают множественный одновременный доступ к одному и тому же ящику, также должны посылать соответствующие немаркированные отклики FETCH и EXPUNGE, если другие агенты изменяют состояние любого флага сообщения или удаляют любое сообщение.
Отклики запросов продолжения команды используют символ "+" вместо метки. Эти отклики посылаются сервером для индикации приема незавершенной команды клиента и готовности приема остальной части команды.
6.1. Отклики сервера – отклики состояния
Статусными откликами являются OK, NO, BAD, PREAUTH и BYE. OK, NO и BAD могут быть маркированными или нет. PREAUTH и BYE – всегда не маркированы.
Статусные отклики могут включать опционный код отклика.
Код отклика состоит из информации, заключенной в квадратные скобки, в форме атома. Далее может следовать пробел и аргументы. Код отклика содержит дополнительную информацию или статусные коды для программы клиента помимо условий OK/NO/BAD. Эти данные определяются, когда клиент может предпринять действия на основе этой дополнительной информации. В настоящее время определены следующие коды откликов:
| ALERT | Текстовое сообщение, содержащее специальное предупреждение, которое должно быть представлено пользователю в форме, привлекающей внимание. |
| NEWNAME | За этим откликом следует имя почтового ящика и новое имя. Команды SELECT или EXAMINE не пройдут, так как ящик места назначения более не существует из-за переименования. Это является указанием для клиента, попытаться повторить команду с новым именем почтового ящика. |
| PARSE | Текстовое сообщение, которое указывает на ошибку при разборе заголовка [RFC-822] или заголовка [MIME-IMB] сообщения в почтовом ящике. |
| PERMANENTFLAGS | Когда за этим кодом следует в скобках список флагов, это указывает, какие из известных флагов могут быть изменены на постоянной основе. Любые флаги, которые указаны в немаркированном отклике FLAGS, но отсутствуют в списке PERMANENTFLAGS, могут быть установлены на постоянной основе. Если клиент пытается запомнить (STORE) флаг, который отсутствует в списке PERMANENTFLAGS, сервер либо отвергнет этот запрос с помощью отклика NO или запомнит состояние только до конца текущей сессии. Список PERMANENTFLAGS может также включать специальный флаг \*, который указывает, что имеется возможность создать новые ключевые слова путем записи этих флагов в почтовом ящике. |
| READ-ONLY | Почтовый ящик выбран в режиме только для чтения или доступ к нему был сменен с read-write на read-only. |
| READ-WRITE | Почтовый ящик находится в режиме read-write, или доступ к нему был сменен с read-only на read-write. |
| TRYCREATE | Попытка выполнения APPEND или COPY оказалась неуспешной из-за того, что почтовый ящик места назначения отсутствует. Это указывает клиенту, что операция может оказаться успешной, если почтовый ящик будет сначала создан с помощью CREATE |
| UIDVALIDITY | Когда за этим кодом следует десятичное число, это указывает на значение уникального идентификатора. |
| UNSEEN | Когда за этим кодом следует десятичное число, это указывает на значение номера первого сообщения без флага \Seen. |
Дополнительные коды откликов определенные конкретным клиентом или сервером должны иметь префикс "X", если они отклоняются от рекомендаций данного документа. Реализации клиента должны игнорировать отклики, которые ими не распознаются.
6.1.1. Отклик OK
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик OK индицирует информационное сообщение от сервера. Если оно маркировано, сообщение указывает на успешное завершение соответствующей команды. Пользователю может быть предложено текстовое информационное сообщение. Немаркированная форма указывает на чисто информационное сообщение; природа информации может быть указана в коде отклика.
Немаркированная форма используется также как один из трех видов оповещения об установлении начального соединения. Эта форма указывает, что еще не выполнена аутентификация и необходима команда LOGIN.
Пример: S: * OK IMAP4rev1 server ready
C: A001 LOGIN fred blurdybloop
S: * OK [ALERT] System shutdown in 10 minutes
S: A001 OK LOGIN Completed
6.1.2. Отклик NO
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик NO указывает на сообщение от сервера об операционной ошибке. В помеченной форме он отмечает неудачное завершение соответствующей команды. Непомеченная форма служит для индикации предупреждения, команда все еще может завершиться успешно. Текстовое сообщение описывает условия.
Пример: C: A222 COPY 1:2 owatagusiam
S: * NO Disk is 98% full, please delete unnecessary data
S: A222 OK COPY completed
C: A223 COPY 3:200 blurdybloop
S: * NO Disk is 98% full, please delete unnecessary data
S: * NO Disk is 99% full, please delete unnecessary data
S: A223 NO COPY failed: disk is full
6.1.3. Отклик BAD
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик BAD отмечает сообщение об ошибке со стороны сервера. В маркированной форме он сообщает об ошибке протокольного уровня в команде клиента; метка отмечает команду, которая вызвала ошибку. Непомеченная форма указывает на ошибку протокольного уровня, для которой нельзя указать команду, вызвавшую ошибку; это может также означать внутреннюю ошибку сервера.
Текстовое сообщение описывает условия.
Пример: C: ...very long command line...
S: * BAD Command line too long
C: ...empty line...
S: * BAD Empty command line
C: A443 EXPUNGE
S: * BAD Disk crash, attempting salvage to a new disk!
S: * OK Salvage successful, no data lost
S: A443 OK Expunge completed
6.1.4. Отклик PREAUTH
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик PREAUTH является всегда непомеченным и представляет собой одну из трех возможных реакций при установлении соединения. Он указывает, что для соединения уже выполнена аутентификация, и команда LOGIN не нужна.
Пример: S: * PREAUTH IMAP4rev1 server logged in as Smith
6.1.5. Отклик BYE
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик BYE является всегда непомеченным, он указывает, что сервер намеривается разорвать соединение. При этом пользователю может быть послано текстовое сообщение, проясняющее статус клиента. Отклик BYE посылается при выполнении одного из четырех условий:
Как часть нормальной процедуры logout. Сервер закроет соединение после отправки маркированного отклика OK на команду LOGOUT. Как уведомление об аварийном прерывании сессии. Сервер немедленно разрывает соединение. Как уведомление о процедуре автоматического logout по причине отсутствия активности. Сервер немедленно разрывает соединение. Как одно из трех возможных сообщений при установлении соединения, уведомляя, что сервер не может установить соединение с данным клиентом. Сервер немедленно разрывает соединение. Отличие между откликом BYE, который является частью обычной процедуры LOGOUT (первый вариант), и BYE при отказе (остальные три варианта), заключается в том, что соединение в последнем случае разрывается немедленно.
Пример: S: * BYE Autologout; idle for too long
6.2. Отклики сервера – сообщения о состоянии сервера и почтового ящика
Эти отклики всегда не маркированы. Они служат для передачи статусной информации сервера и почтового ящика клиенту. Большинство этих откликов являются результатом команд, носящих то же имя.
6.2.1. Отклик CAPABILITY
Содержимое: список возможностей.
Отклик CAPABILITY возникает в результате исполнения одноименной команды. Список возможностей, содержащийся в перечне наименований, разделенных пробелами, характеризует функции, поддерживаемые сервером. Список возможностей должен включать в себя атом "IMAP 4.1".
Имя возможности, которое начинается с "AUTH=" указывает, что сервер поддерживает данный механизм аутентификации. Другие наименования возможностей отмечают, что сервер поддерживает расширение, модификацию или усовершенствования протокола IMAP 4.1. Отклик сервера должен соответствовать данному документу до тех пор, пока клиент использует команды, согласованные со списком возможностей.
Имена возможностей должны либо начинаться с "X", либо быть стандартными, либо соответствовать расширениям IMAP 4.1, модификациям или усовершенствованиям, зарегистрированным IANA. Сервер не должен предлагать незарегистрированные или нестандартные имена возможностей, если их имена не начинаются с символа "X".
Реализациям клиента не следует требовать каких-либо имен возможностей, отличных от "IMAP 4.1", они должны игнорировать неизвестные имена возможностей.
Пример: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
6.2.2. Отклик LIST
Содержимое: атрибуты имени, иерархический разделитель, имя.
Отклик LIST посылается как результат команды LIST. Он возвращает одно имя, которое соответствует спецификации LIST. Допускается несколько откликов LIST на одну команду.
Определено четыре атрибута имени:
| \Noinferiors | Дочерние уровни иерархии не могут иметь то же самое имя. Не существует дочерних уровней в настоящее время, и они не могут быть созданы в будущем. |
| \Noselect | Не допускается использование данного имени для именования почтового ящика, который может быть выбран. |
| \Marked | Почтовый ящик помечен сервером как "interesting"; почтовый ящик, вероятно, содержит сообщения, которые добавлены со времени, когда почтовый ящик последний раз был выбран. |
| \Unmarked | Почтовый ящик не содержит каких-либо дополнительных сообщений, со времени, когда почтовый ящик последний раз был выбран. |
Иерархическим разделителем является символ, используемый для разграничения уровней иерархии имен почтового ящика. Клиент может использовать разделитель для формирования дочерних уровней в почтовом ящике, а также для поиска в иерархической системе имен. Все дочерние уровни верхнего уровня иерархии должны использовать один и тот же тип разделителя. Иерархический разделитель NIL означает, что никакой иерархии нет.
Имя представляет собой однозначную иерархию (слева направо) и должно быть пригодным для использования в качестве шаблона командами LIST и LSUB. Если не использован атрибут \Noselect, имя должно быть пригодно в качестве аргумента команд, типа SELECT, которые требуют ввода имени почтового ящика.
Пример: S: * LIST (\Noselect) "/" ~/Mail/foo
6.2.3. Отклик LSUB
Содержимое: атрибуты имени, иерархический разграничитель, имя.
Отклик LSUB является результатом команды LSUB. Он возвращает одно имя, которое соответствует спецификации LSUB. Допускается несколько откликов на одну команду LSUB. Формат данных идентичен используемому в отклике LIST.
Пример: S: * LSUB () "." #news.comp.mail.misc
6.2.4. Отклик STATUS
Содержимое: имя, статусный список, заключенный в скобки.
Отклик STATUS является результатом команды STATUS. Он возвращает имя почтового ящика, которое соответствует спецификации STATUS, и запрашиваемую статусную информацию почтового ящика.
Пример: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
6.2.5. Отклик SEARCH
Содержимое: нуль или более чисел.
Отклик SEARCH является результатом команды SEARCH или UID SEARCH. Числа относятся к тем сообщениям, которые отвечают критериям отбора. Для SEARCH это порядковые номера сообщений, а для UID SEARCH – их уникальные идентификаторы. Числа отделяются друг от друга пробелами.
Пример: S: * SEARCH 2 3 6
6.2.6. Отклик FLAGS
Содержимое: список флагов, заключенный в скобки.
Отклик FLAGS является результатом команды SELECT или EXAMINE. Список флагов, заключенный в скобки определяет флаги (системные флаги), которые могут использоваться для данного почтового ящика.
Допускаются флаги, отличные от системных, это зависит от реализации сервера. Отклик FLAGS должен записываться клиентом.
Пример: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
6.3. Отклики сервера – размер почтового ящика
Эти отклики являются немаркированными. Они передают от сервера клиенту информацию об изменении размера почтового ящика. Число, которое следует за символом "*" определяет количество сообщений.
6.3.1. Отклик EXISTS
Содержимое: отсутствует.
Отклик EXISTS сообщает о числе сообщений в почтовом ящике. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение). Отклик EXISTS должен регистрироваться клиентом.
Пример: S: * 23 EXISTS
6.3.2. Отклик RECENT
Содержимое: отсутствует.
Отклик RECENT сообщает число сообщений с флагами \Recent. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение).
Замечание: Нельзя гарантировать, чтобы порядковые номера для последних сообщений образовывали в почтовом ящике непрерывный ряд с предыдущими. Примерами, когда складывается такая ситуация могут служить варианты: несколько клиентов, имеют один и тот же открытый почтовый ящик; или случай, когда сообщения в почтовом ящике переставлены не-IMAP приложением.
Единственным способом идентифицировать последние сообщения является рассмотрение флагов \Recent, или выполнение команды SEARCH RECENT. Информация отклика RECENT должна регистрироваться клиентом.
Пример: S: * 5 RECENT
6.4. Отклики сервера – статусное сообщение
Эти отклики являются немаркированными. Они несут информацию о том, как сообщения доставляются от сервера к клиентам, и возникают как результат работы одноименных команд. Сразу за символом "*" следует число, которое является порядковым номером сообщения.
6.4.1. Отклик EXPUNGE
Содержимое: отсутствует.
Отклик EXPUNGE уведомляет, сообщение с каким порядковым номером удалено из почтового ящика.
Порядковые номера последующих сообщений немедленно уменьшаются на единицу.
Как результат этого немедленного уменьшения порядковых номеров следует рассматривать то, что порядковые номера сообщений, появляющиеся при последующих командах EXPUNGE, зависят от того, в каком порядке удаляются сообщения. Например, если последние 5 сообщений в почтовом ящике с 9 сообщениями стерты, сервер, удаляющий записи “снизу-вверх” пошлет 5 немаркированных откликов EXPUNGE (с номером 5), в то время как сервер, стирающий записи "сверху вниз", пошлет немаркированные отклики с номерами 9, 8, 7, 6 и 5.
Отклик EXPUNGE не должен посылаться, когда не исполняется никакая команда, или при отклике на команды FETCH, STORE или SEARCH. Это правило необходимо, чтобы предотвратить потерю синхронизации нумерации для клиента и сервера.
Информация отклика EXPUNGE должна регистрироваться клиентом.
Пример: S: * 44 EXPUNGE
6.4.2. Отклик FETCH
Содержимое: текст сообщения.
Отклик FETCH возвращает данные о сообщении клиенту. Данные сформированы в группы из имени элемента и его значения в скобках. Этот отклик является следствием команды FETCH или STORE, а также одностороннего решения сервера (например, об изменении флагов). В настоящее время существуют следующие информационные элементы:
BODY Форма BODYSTRUCTURE без расширения данных.
BODY[]>
Строка, отражающая содержимое специфицированной секции. Строка должна интерпретироваться клиентом согласно транспортной кодировке, типу и субтипу тела.
Если специфицирован начальный октет, то это субстрока полного содержимого тела, начинающаяся с заданного октета. Это означает, что BODY[] может быть укорочено, но BODY[] никогда не укорачивается.
Если идентификатор [CHARSET] является частью списка параметров тела секции, допустимы 8-битовые текстовые данные. Заметьте, что заголовки (спецификаторы частей HEADER, MIME или часть заголовка секции MESSAGE/RFC822), должны содержать только 7-битовые символы (применение 8-битовых символов в заголовке запрещено).
Заметим также, что пустая строка в конце заголовка всегда включается в текст заголовка.
Не текстовые данные, такие как двоичные, должны передаваться закодированными в текстуальной форме, например BASE64. Чтобы получить исходные двоичные данные клиент должен декодировать полученную последовательность.
BODYSTRUCTURE - список, заключенный в скобки, который описывает [MIME-IMB],
структура тела сообщения.
Эта структура вычисляется сервером путем разбора полей заголовка [MIME-IMB], и подставления при необходимости значений по умолчанию.
Например, простое текстовое сообщение из 48 строк и 2279 октетов может иметь структуру тела: ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48)
Если имеется несколько частей, они выделяются вложенными скобками. Вместо типа тела в качестве первого элемента списка используется тело с иерархической структурой. Вторым элементом списка, заключенного в скобки, является составной субтип (mixed, digest, parallel, alternative, и т.д.).
Например, сообщение из двух частей, включающее в себя текст и приложение, закодированное в BASE64, может иметь структуру тела: (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") "" "Compiler diff" "BASE64" 4554 73) "MIXED"))
Данные расширения следуют за составным субтипом. Данные расширения никогда не присылаются при доставке тела, но могут быть доставлены с помощью BODYSTRUCTURE. Данные расширения, если они присутствуют, должны иметь следующий формат:
Список параметров тела, заключенный в скобки.
Список содержит пары атрибут/значение [например, ("foo" "bar" "baz" "rag"), где "bar" представляет собой значение "foo", а "rag" является значением "baz"] как это определено в [MIME-IMB].
Размещение тела
Список, заключенный в скобки, состоящий из строки типа размещения, за которой следует список пар атрибут/значение. Имена типов размещения и атрибутов будут определены в будущих стандартах.
Язык тела
Строка или список в скобках, определяющие язык, так как это задано в [LANGUAGE-TAGS].
Любое из последующих расширений данных в данной версии протокола не определено. Такие расширения могут состоять из нуля или более NIL-строк, чисел, или вложенных списков таких данных, заключенных в скобки. Реализации клиента, которые осуществляют доставку BODYSTRUCTURE, должны быть готовы принять такие расширения данных. Реализации сервера не должны посылать такие расширения, до тех пор, пока они не войдут в новую версию протокола. Базовые поля несоставной части тела размещаются в следующем порядке:
Тип тела
Строка, описывающая имя типа содержимого, как это определено в [MIME-IMB].
Субтип тела
Строка, описывающая имя субтипа, как это определено в [MIME-IMB].
Список параметров тела, заключенный в скобки
Список пар атрибут/значение, заключенный в скобки, [например, ("foo" "bar" "baz" "rag"), где "bar" является значением "foo", а "rag" – значением "baz"], как это описано в [MIME-IMB].
Идентификатор тела
Строка, описывающая идентификатор содержимого, как это определено в [MIME-IMB].
Описание тела
Строка, предоставляющая описание содержимого, как это задано в [MIME-IMB].
Шифрование тела
Строка, предоставляющая транспортную кодировку, как это задано в [MIME-IMB].
Размер тела
Число, указывающее размер тела в октетах. Заметьте, что этот размер характеризует размер тела с учетом транспортного кодирования. Размер исходного текста может быть иным.
Тип тела MESSAGE и субтип RFC822 сразу после базовых полей содержат структуру заголовка, структуру тела и размер вложенного сообщения в строках.
Тип тела TEXT сразу после базовых полей содержат размер тела в строках. Заметьте, что этот размер отражает размер фрагмента после выполнения транспортного кодирования.
Данные расширения следуют после базовых полей и полей, перечисленных выше и зависящих от типа. Данные расширения никогда не транспортируются при передаче тела, но могут быть пересланы при доставке BODYSTRUCTURE. Данные расширения, если они присутствуют, должны быть упорядочены.
Данные расширения для несоставной части тела располагаются в следующем порядке:
MD5 тела
Строка, содержащая значение MD5 тела, как это описано в [MD5].
Размещение тела
Список, заключенный в скобки, с тем же содержимым и функциями, что и размещение тела для составной части тела.
Язык тела
Строка или список, заключенный в скобки, определяющие язык тела, как это задано в [LANGUAGE-TAGS].
Любые последующие данные расширения пока не определены в данной версии протокола.
ENVELOPE - список, заключенный в скобки, который описывает структуру заголовка (конверта) сообщения. Он вычисляется сервером в результате разбора заголовка [RFC-822], при необходимости некоторым полям присваиваются значения по умолчанию.
Поля структуры конверта размещаются в следующем порядке: дата, subject (предмет сообщения), from (от), отправитель, reply-to (ответ на), to, cc, bcc, in-reply-to (в ответ на), и идентификатор сообщения. Поля дата, subject, in-reply-to и идентификатор сообщения являются строками. Поля from, отправитель, reply-to, to, cc и bcc являются списками адресных структур, заключенными в скобки.
Адресная структура представляет собой список, который описывает электронный почтовый адрес. Поля адресной структуры размещаются в следующем порядке: персональное имя, [SMTP] @-домен (маршрут отправителя), имя почтового ящика и имя ЭВМ.
Синтаксис группы [RFC-822] определяется специальной формой адресной структуры, в которой поле имени ЭВМ равно NIL. Если поле имени почтового ящика также равно NIL, это является концом группового маркера (двоеточие в синтаксисе RFC 822). Если поле имени почтового ящика не равно NIL, это обозначает начало группового маркера, а поле имени почтового ящика содержит имя группы.
Любое поле в конверте или адресной структуре, которое не используется, характеризуется значением NIL.
Заметим, что сервер должен заполнять по умолчанию поля reply-to и sender из поля from.
| FLAGS | Список флагов, установленных для данного сообщения, заключенный в скобки. |
| INTERNALDATE | Строка, представляющая внутреннюю дату сообщения. |
| RFC822 | Эквивалент BODY[]. |
| RFC822.HEADER | Эквивалент BODY.PEEK[HEADER]. |
| RFC822.SIZE | Число, выражающее размер сообщения [RFC-822]. |
| RFC822.TEXT | Эквивалент BODY[TEXT]. |
| UID | Число, выражающее уникальный идентификатор сообщения. |
6.5 Отклики сервера – запрос продолжения команды
Отклик на запрос продолжения команды вместо метки выделяется символом "+". Эта форма отклика указывает на то, что сервер готов принять продолжение команды от клиента. Остальная часть этого отклика имеет текстовую форму.
Этот отклик используется командой AUTHORIZATION, для того чтобы передать данные от сервера клиенту, и запросить дополнительные данные у клиента. Этот отклик применяется также, если аргументом какой-то команды является литерал.
Клиенту не позволено посылать литеральные октеты, если только сервер в явной форме не запросил их. Это позволяет серверу обрабатывать команды и отвергать ошибки строчка за строчкой. Остальная часть команды, включая CRLF, завершающие команду, следует за октетами литерала. Если имеются какие-либо дополнительные аргументы команды, за литеральными октетами следует пробел, после чего передаются аргументы.
Пример: C: A001 LOGIN {11}
S: + Ready for additional command text
C: FRED FOOBAR {7}
S: + Ready for additional command text
C: fat man
S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP"
7. Пример соединения IMAP 4.1
Последующее является записью для соединения IMAP 4.1. (Данный пример и нижеприведенное описание синтаксиса практически без изменения взято из документа RFC-2060).
S: * OK IMAP4rev1 Service Ready
C: a001 login mrc secret
S: a001 OK LOGIN completed
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK [ UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev1 WG mtg summary and minutes"
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
((NIL NIL "imap" "cac.washington.edu"))
((NIL NIL "minutes" "CNRI.Reston.VA.US")
("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
"")
BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
S: a003 OK FETCH completed
C: a004 fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {350}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray gray@cac.washington.edu
S: Subject: IMAP4rev1 WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US, John Klensin KLENSIN@INFOODS.MIT.EDU
S: Message-Id: B27397-0100000@cac.washington.edu
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: a004 OK FETCH completed
C: a005 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
S: a005 OK +FLAGS completed
C: a006 logout
S: * BYE IMAP4rev1 server terminating connection
S: a006 OK LOGOUT completed
8. Формальный синтаксис
Последующая синтаксическая спецификация использует нотацию Бакуса-Наура (BNF - Backus-Naur Form), как это описано в [RFC-822] с одним исключением, разделителем, используемым в конструкции "#", служит одиночный пробел (SPACE), а не одна или более запятых.
В случае альтернативных или опционных правил, в которых последующее правило перекрывается с более ранним, более приоритетным считается правило, встретившееся первым. Некоторые, но не все случаи таких правил представлены ниже. Если не указано обратного, все буквенные символы не зависят от использования строчных или прописных букв. Конкретные программные реализации должны воспринимать такие строки при любом написании.
address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox SPACE addr_host ")"
addr_adl ::= nstring
;; Хранит маршрут из route-addr [RFC-822], если не равно нулю
addr_host ::= nstring
;; NIL указывает на синтаксис группы [RFC-822].
;; В противном случае, содержит имя домена [RFC-822]
addr_mailbox ::= nstring
;; NIL индицирует конец группы [RFC-822]; если не NIL, а addr_host равно NIL,
;; содержит имя группы ;; [RFC-822].
;; В противном случае, содержит локальную часть [RFC-822]
addr_name ::= nstring
;; Содержит фразу из почтового ящика [RFC-822], если не NIL
alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
"I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
"Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
"Y" / "Z" /
"a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
"i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
"q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
"y" / "z"
;; Чувствительно к набору строчными или прописными буквами
append ::= "APPEND" SPACE mailbox [SPACE flag_list]
[SPACE date_time] SPACE literal
astring ::= atom / string
atom ::= 1*ATOM_CHAR
ATOM_CHAR ::=
atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards /
quoted_specials
authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
auth_type ::= atom
;; Определено в [IMAP-AUTH]
base64 ::= *(4base64_char) [base64_terminal]
base64_char ::= alpha / digit / "+" / "/"
base64_terminal ::= (2base64_char "==") / (3base64_char "=")
body ::= "(" body_type_1part / body_type_mpart ")"
body_extension ::= nstring / number / "(" 1#body_extension ")"
;; Будущее расширение. Реализации клиента должны воспринимать поля
;; body_extension. Реализации сервера не должны генерировать
;; поля body_extension, за исключением случаев, закрепленных в будущих
;; стандартах или зарегистрированных модификациях уже существующих норм.
body_ext_1part ::= body_fld_md5 [SPACE body_fld_dsp
[SPACE body_fld_lang
[SPACE 1#body_extension]]]
;; не должны присылаться при non-extensible доставке "BODY"
body_ext_mpart ::= body_fld_param
[SPACE body_fld_dsp SPACE body_fld_lang
[SPACE 1#body_extension]]
;; MUST NOT be returned on non-extensible "BODY" fetch
body_fields ::= body_fld_param SPACE body_fld_id SPACE
body_fld_desc SPACE body_fld_enc SPACE
body_fld_octets
body_fld_desc ::= nstring
body_fld_dsp ::= "(" string SPACE body_fld_param ")" / nil
body_fld_enc ::= ( ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
"QUOTED-PRINTABLE") ) / string
body_fld_id ::= nstring
body_fld_lang ::= nstring / "(" 1#string ")"
body_fld_lines ::= number
body_fld_md5 ::= nstring
body_fld_octets ::= number
body_fld_param ::= "(" 1#(string SPACE string) ")" / nil
body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)
[SPACE body_ext_1part]
body_type_basic ::= media_basic SPACE body_fields
;; субтип MESSAGE не должен следовать "RFC822"
body_type_mpart ::= 1*body SPACE media_subtype
[SPACE body_ext_mpart]
body_type_msg ::= media_message SPACE body_fields SPACE envelope
SPACE body SPACE body_fld_lines
body_type_text ::= media_text SPACE body_fields SPACE body_fld_lines
capability ::= "AUTH=" auth_type / atom
;; Новая возможность должна начинаться с "X" или быть зарегистрирована
;; IANA в качестве стандарта или являться усовершенствованием
;; существующего стандарта
capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1"
[SPACE 1#capability]
;; серверы IMAP 4.1, которые предлагают совместимость с RFC 1730
;; должны включать "IMAP4" в список возможностей этой реализации
CHAR ::= 0x01 - 0x7f>
CHAR8 ::=
command ::= tag SPACE (command_any / command_auth /
command_nonauth / command_select) CRLF
;; Modal based on state
command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
;; Справедливо для всех состояний
command_auth ::= append / create / delete / examine / list / lsub /
rename / select / status / subscribe / unsubscribe
;; Работает только в состояниях Authenticated или Selected
command_nonauth ::= login / authenticate
;; Работает только в состоянии Non-Authenticated
command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" /
copy / fetch / store / uid / search
;; Работает только в состоянии Selected
continue_req ::= "+" SPACE (resp_text / base64)
copy ::= "COPY" SPACE set SPACE mailbox
CR ::=
create ::= "CREATE" SPACE mailbox
;; Использование INBOX не приводит к ошибке
CRLF ::= CR LF
CTL ::= 0x00 - 0x1f, 0x7f>
date ::= date_text / date_text
date_day ::= 1*2digit
;; День месяца
date_day_fixed ::= (SPACE digit) / 2digit
;; Версия с фиксированным форматом date_day
date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
"Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
date_text ::= date_day "-" date_month "-" date_year
date_year ::= 4digit
date_time ::= date_day_fixed "-" date_month "-" date_year
SPACE time SPACE zone
delete ::= "DELETE" SPACE mailbox
;; Использование INBOX не приводит к ошибке
digit ::= "0" / digit_nz
digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
envelope ::= "(" env_date SPACE env_subject SPACE env_from
SPACE env_sender SPACE env_reply_to SPACE env_to
SPACE env_cc SPACE env_bcc SPACE env_in_reply_to
SPACE env_message_id ")"
env_bcc ::= "(" 1*address ")" / nil
env_cc ::= "(" 1*address ")" / nil
env_date ::= nstring
env_from ::= "(" 1*address ")" / nil
env_in_reply_to ::= nstring
env_message_id ::= nstring
env_reply_to ::= "(" 1*address ")" / nil
env_sender ::= "(" 1*address ")" / nil
env_subject ::= nstring
env_to ::= "(" 1*address ")" / nil
examine ::= "EXAMINE" SPACE mailbox
fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
"FAST" / fetch_att / "(" 1#fetch_att ")")
fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
"RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
"BODY" ["STRUCTURE"] / "UID" /
"BODY" [".PEEK"] section
[""]
flag ::= "\Answered" / "\Flagged" / "\Deleted" /
"\Seen" / "\Draft" / flag_keyword / flag_extension
flag_extension ::= "\" atom
;; Будущее расширение. Реализации клиента должны воспринимать
;; флаги flag_extension. Реализации сервера не должны генерировать
;; флаги flag_extension, за исключением случаев, определенных в
;; будущих стандартах или зарегистрированных модификациях
;; данной спецификации.
flag_keyword ::= atom
flag_list ::= "(" #flag ")"
greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
header_fld_name ::= astring
header_list ::= "(" 1#header_fld_name ")"
LF ::=
list ::= "LIST" SPACE mailbox SPACE list_mailbox
list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string
list_wildcards ::= "%" / "*"
literal ::= "{" number "}" CRLF *CHAR8
;; Число характеризует количество октетов CHAR8
login ::= "LOGIN" SPACE userid SPACE password
lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox
mailbox ::= "INBOX" / astring
;; INBOX не чувствителен к использованию строчных или прописных букв.
;; все версии написания INBOX (напр., "iNbOx") должны
;; интерпретироваться как INBOX, а не как строку.
mailbox_data ::= "FLAGS" SPACE flag_list /
"LIST" SPACE mailbox_list /
"LSUB" SPACE mailbox_list /
"MAILBOX" SPACE text /
"SEARCH" [SPACE 1#nz_number] /
"STATUS" SPACE mailbox SPACE
"(" # number SPACE "EXISTS" / number SPACE "RECENT"
mailbox_list ::= "(" #("\Marked" / "\Noinferiors" /
"\Noselect" / "\Unmarked" / flag_extension) ")"
SPACE ( QUOTED_CHAR / nil) SPACE mailbox
media_basic ::= ( ("APPLICATION" / "AUDIO" / "IMAGE" /
"MESSAGE" / "VIDEO") ) / string)
SPACE media_subtype
;; Определено в [MIME-IMT]
media_message ::= "MESSAGE" SPACE "RFC822"
;; Определено в [MIME-IMT]
media_subtype ::= string
;; Определено в [MIME-IMT]
media_text ::= "TEXT" SPACE media_subtype
;; Определено в [MIME-IMT]
message_data ::= nz_number SPACE ("EXPUNGE" /
("FETCH" SPACE msg_att))
msg_att ::= "(" 1#("ENVELOPE" SPACE envelope /
"FLAGS" SPACE "(" #(flag / "\Recent") ")" /
"INTERNALDATE" SPACE date_time /
"RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
"RFC822.SIZE" SPACE number /
"BODY" ["STRUCTURE"] SPACE body /
"BODY" section [""] SPACE nstring /
"UID" SPACE uniqueid) ")"
nil ::= "NIL"
nstring ::= string / nil
number ::= 1*digit
;; 32- битное целое число без знака
;; (0 nz_number ::= digit_nz *digit
;; 32-битное не равное нулю целое число без знака
;; (0 < n < 4,294,967,296)
password ::= astring
quoted ::= *QUOTED_CHAR
QUOTED_CHAR ::= /
"\" quoted_specials
quoted_specials ::= / "\"
rename ::= "RENAME" SPACE mailbox SPACE mailbox
;; Использование INBOX в качестве места назначения не дает ошибки
response ::= *(continue_req / response_data) response_done
response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
mailbox_data / message_data / capability_data)
CRLF
response_done ::= response_tagged / response_fatal
response_fatal ::= "*" SPACE resp_cond_bye CRLF
;; Сервер закрывает соединение немедленно
response_tagged ::= tag SPACE resp_cond_state CRLF
resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text
;; Условие аутентификации
resp_cond_bye ::= "BYE" SPACE resp_text
resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text
;; Условие состояния
resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)
;; текст не должен начинаться с "[" или "="
resp_text_code ::= "ALERT" / "PARSE" /
"PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /
"READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
"UIDVALIDITY" SPACE nz_number /
"UNSEEN" SPACE nz_number /
atom [SPACE 1*]
search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]
1#search_key
;; Символьный набор [CHARSET] должен быть зарегистрирован IANA
search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /
"BEFORE" SPACE date / "BODY" SPACE astring /
"CC" SPACE astring / "DELETED" / "FLAGGED" /
"FROM" SPACE astring /
"KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
"ON" SPACE date / "RECENT" / "SEEN" /
"SINCE" SPACE date / "SUBJECT" SPACE astring /
"TEXT" SPACE astring / "TO" SPACE astring /
"UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
"UNKEYWORD" SPACE flag_keyword / "UNSEEN" /
;; Выше этой строки все в [IMAP2]
"DRAFT" /
"HEADER" SPACE header_fld_name SPACE astring /
"LARGER" SPACE number / "NOT" SPACE search_key /
"OR" SPACE search_key SPACE search_key /
"SENTBEFORE" SPACE date / "SENTON" SPACE date /
"SENTSINCE" SPACE date / "SMALLER" SPACE number /
"UID" SPACE set / "UNDRAFT" / set /
"(" 1#search_key ")"
section ::= "[" [section_text / (nz_number *["." nz_number]
["." (section_text / "MIME")])] "]"
section_text ::= "HEADER" / "HEADER.FIELDS" [".NOT"]
SPACE header_list / "TEXT"
select ::= "SELECT" SPACE mailbox
sequence_num ::= nz_number / "*"
;; * является наибольшим используемым числом. Для порядковых номеров
;; сообщений оно равно количеству сообщений в почтовом ящике.
;; Для уникальных идентификаторов оно равно уникальному
;; идентификатору последнего сообщения в почтовом ящике./p> set ::= sequence_num / (sequence_num ":" sequence_num) /
(set "," set)
;; Идентифицирует набор сообщений. Для порядковых номеров
;; сообщений это последовательность чисел с 1 до числа
;; сообщений в почтовом ящике.
;; Запятая разграничивает индивидуальные номера, двоеточие
;; указывает на диапазон чисел включительно.
;; Пример для почтового ящика с 15 сообщениями: 2,4:7,9,12:*
;; эквивалентно 2,4,5,6,7,9,12,13,14,15.
SPACE ::=
status ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")"
status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
"UNSEEN"
store ::= "STORE" SPACE set SPACE store_att_flags
store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE
(flag_list / #flag)
string ::= quoted / literal
subscribe ::= "SUBSCRIBE" SPACE mailbox
tag ::= 1*
text ::= 1*TEXT_CHAR
text_mime2 ::= "=?" "?" "?"
"?="
;; Синтаксис определен в [MIME-HDRS]
TEXT_CHAR ::=
time ::= 2digit ":" 2digit ":" 2digit
;; Часы, минуты, секунды
uid ::= "UID" SPACE (copy / fetch / search / store)
;; Уникальные идентификаторы используются вместо
;; последовательных номеров сообщения.
uniqueid ::= nz_number
;; В возрастающем порядке
unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox
userid ::= astring
x_command ::= "X" atom
zone ::= ("+" / "-") 4digit
;; Число из 4 цифр со знаком hhmm, представляющее часы и минуты к западу от Гринвича
;; (Это число отличается от Universal Time). Вычитая временную зону из данного времени, можно получить
;; форму UT. Зона Universal Time равна "+0000". Соображения безопасности Протокольные операции IMAP 4.1, включая данные электронной почты, передаются через сеть открытым текстом, если только не согласовано применение конфиденциальных методов обмена посредством команды AUTHENTICATE.
Сообщения об ошибках сервера для команды AUTHENTICATE, которая не прошла из-за неверных параметров аутентификации, не должна уточнять какой из параметров содержит ошибку.
Использование команды LOGIN осуществляет передачу паролей открытым текстом. Этого можно избежать, используя для этого команду AUTHENTICATE.
A. Библиография
| [ACAP] | Myers, J. "ACAP -- Application Configuration Access Protocol", Work in Progress. |
| [CHARSET] | Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. |
| [DISPOSITION] | Troost, R., and Dorner, S., " Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995. |
| [IMAP-AUTH] | Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. Carnegie-Mellon University, December 1994. |
| [IMAP-COMPAT] | Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC 2061, University of Washington, November 1996. |
| [IMAP-DISC] | Austein, R., "Synchronization Operations for Disconnected IMAP4 Clients", Work in Progress. |
| [IMAP-HISTORICAL] | Crispin, M. "IMAP4 Compatibility with IMAP2 and IMAP2bis", RFC 1732, University of Washington, December 1994. |
| [IMAP-MODEL] | Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, University of Washington, December 1994. |
| [IMAP-OBSOLETE] | Crispin, M., "Internet Message Access Protocol - Obsolete Syntax", RFC 2062, University of Washington, November 1996 |
| [IMAP2] | Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC 1176, University of Washington, August 1990. |
| [LANGUAGE-TAGS] | Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. |
| [MD5] | Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995. |
| [MIME-IMB] | Freed, N., and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. |
| [MIME-IMT] | Freed, N., and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 2046, November 1996. |
| [MIME-HDRS] | Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. |
| [RFC-822] | Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982. |
| [SMTP] | Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. |
| [UTF-7] | Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe Transformation Format of Unicode", RFC 1642, July 1994. |
Схемы каналов, использующих городскую телефонную сеть
Рисунок 1.5. Схемы каналов, использующих городскую телефонную сеть
На Рисунок 1.5 показана схема построения сети с использованием исключительно соединений типа точка-точка. Это наиболее часто встречающийся, но не единственный вариант. Дорога 'от околицы до околицы' прокладывается там, где она нужна и теми, кому она нужна непосредственно, но, согласитесь, построить так магистраль Москва Санкт-Петербург нельзя. При построении крупных общенациональных и интернациональных сетей применяются сверхширокополосные каналы и схемы типа опорной сети (backbone). Узлы такой сети могут располагаться в каких-то крупных организациях или быть самостоятельными (принадлежать государственным PTT). Такие сети обычно базируются на протоколах SDH (Sonet). Информация в этих сетях передается в виде больших блоков (виртуальных контейнеров). Использование опорной сети обычно оправдано при организации интернациональных связей, но бывают и исключения. Примером такого исключения является Московская опорная сеть, построенная на основе FDDI (100Мбит/с) и объединяющая более десяти научных организаций (длина первой очереди около 30 км). Московская сеть выполнена по схеме с 'прозрачными' IP-мостами, обычно же более мощные опорные сети маршрутизируемы, то есть блоки данных адресуются конкретным узлам, где они разбираются и сортируются. Контейнер может содержать сообщения, адресованные разным получателям, что несколько противоречит идеологии протоколов TCP/IP. IP-пакеты могут вкладываться в эти контейнеры и транспортироваться до заданного узла опорной сети. Классическим примером опорной сети является E-bone (Европейская опорная сеть). Эта сеть объединяет 27 стран (России в этом списке нет) и более 60 сервис-провайдеров, пропускная способность для различных участков лежит в пределах 2-34Мбит/с. Опорная сеть подобна международной автомагистрали, по ней добираются до ближайшего к точке назначения узла, а далее по 'проселочным' каналам до конечного адресата.
Резкое увеличение передаваемых объемов информации в локальных и региональных сетях привело к исчерпанию имеющихся ресурсов, а реальные прогнозы потребностей указывают на продолжение роста потоков в десятки и сотни раз.
Единственной технологией, которая способна удовлетворить эти потребности, являются оптоволоконные сети (Sonet, SDH, ATM, FDDI, Fiber Channel). Каналы этих сетей уже сегодня способны обеспечить пропускную способность 155-622 Мбит/с, ведутся разработки и испытания каналов с пропускной способностью в 2-20 раз больше, например, гигабитного ethernet. Осваивается техника мультиплексирования частот в оптоволокне (WDM), что позволяет поднять его широкополосность в 32 раза и в перспективе довести быстродействие каналов до 80 Гбит/с и более. По мере роста пропускной способности возрастают проблемы управления, синхронизации и надежности. Практически все сети строятся сегодня с использованием последовательных каналов. Это связано прежде всего со стоимостью кабелей, хотя и здесь существуют исключения (например, HIPPI). Разные сетевые услуги предъявляют разные требования к широкополосности канала. На Рисунок 1.6 представлены частотные диапазоны для основных видов телекоммуникационных услуг. В Интернет практически все перечисленные услуги доступны уже сегодня (кроме ТВ высокого разрешения). Стремительно развиваются распределенные системы вычислений (например, проект GREED), управления и информационного обслуживания. Современная технология микропроцессоров предполагает достижение быстродействия в 5 Гбит/с к 2003-4 годам (технология с характеристическим размером объектов на кристалле 80-130 нм).
Словарь
14. Словарь
В этом разделе содержится словарь некоторых терминов, используемых в данной спецификации.
| Имя | Описание |
| Аутентификатор | Организация, которая запрашивает аутентификацию другой организации |
| Аутентифицируемый | Организация, которая осуществляет аутентификацию у аутентификатора |
| Рабочая ошибка (Business Error) | Смотри компонент Status. |
| Вид платежа (Brand) | Вид платежа представляет собой идентификатор определенного типа платежного инструмента. Список видов платежа явлется перечнем платежных опций, которые предоставляются продавцом покупателю и из которого последний выбирает вид оплаты. Каждый вид платежа может иметь разных кассиров. Примеры видов платежей включают в себя:
о частные и корпоративные виды платежей, например MasterCard, Visa, American Express, Diners Club, American Express, Mondex, GeldKarte, CyberCash, и т.д.. вльготные виды платежа (смотри ниже). Последние включают в себя: o магазинные виды платежа, где платежный инструмент предоставляется покупателю конкретным продавцом, например Walmart, Sears или Marks and Spencer (UK) o комбинированные виды платежа, например American Advantage Visa, где компания использует свою собственную системы о платы, которая совмещается с каким-то корпоративным видом платежей. |
| Покупатель | Организация, которая обычно платит за товары или услуги. |
| ContentSoftwareId | Содержит информацию, которая идентифицирует программу, генерирующую содержимое элемента. Ее целью является помощь в разрешении проблем совместимости, которые могут возникнуть в результате несоответствия между сообщениями, выработанными различными программами. Это текстовая строка на языке, определенном xml:lang. Этот идентификатор должен содержать как минимум:
наименования разработчика программы
название программы
версию программы и
структуру программы
Рекомендуется, чтобы этот атрибут включался всякий раз, когда программа, которая сформировала содержимое, не может быть идентифицирована атрибутом SoftwareID Id-компонента сообщения (смотри раздел 3.3.2) |
| Агент обслуживания | Организация, которая обслуживает покупателя, обычно от имени продавца. Примеры обслуживания покупателя включают в себя, реагирование на задачи, которые ставит покупатель в ходе реализации транзакций IOTP, в которых он участвует. |
| Агент доставки | Организация, которая непосредственно доставляет товары или услуги покупателю от имени продавца. Доставка может иметь цифровую форму (напр., в виде сообщений [MIME]), или физическую форму с привлечением почты или курьеров. |
| Документальный обмен | Документальный обмен состоит из последовательности сообщений, которыми обмениваются партнеры в рамках одного или двух торговых операций одновременно. Документальные обмены могут комбинироваться, образуя конкретную транзакцию IOTP. |
| Двойственный вид платежа (Dual Brand) | Двойственный вид платежа означает, что один платежный инструмент может использоваться так, как будто имеются два независимых вида платежа. Например, японская карта "UC" MasterCard может быть использована как UC-карта или как обычная MasterCard. Платежи с помощью UC-карты и MasterCard могут иметь разных Кассиров. Это означает, что:
o Продавец рассматривает, например "UC" и "MasterCard" как два независимых вида платежа, когда предлагает Покупателю список видов платежей, Покупатель выбирает вид платежа, например "UC" или "MasterCard, o Приложение IOTP Покупателя определяет, какой платежный инструмент подходит для выбранного вида платежа, и делает свой выбор. |
| Блок Error | Блок Error сообщает, что в полученном сообщении IOTP обнаружена техническая ошибка. Обычно технические ошибки вызываются ошибками в XML или сбоями в процессе обработки сообщения. Часто генерация или получение блока Error вызывает прерывание транзакции. Эти ошибки отличаются от рабочих ошибок (Business Error), о которых сообщается в компонентах Status. Последние ошибки также могут привести к срыву выполнения транзакции. |
| Блок Exchange | Блок Exchange посылается при торговом обмене от одной торговой роли к другой. Он содержит один или более торговых компонентов. Блоки Exchange при торговом обмене всегда посылаются после блоков Request и до блока Response (отклика). Соджержимое блока Exchange зависит от типа торгового обмена. |
| Сообщение IOTP | Сообщение IOTP является самой внешней структурой, в которую помещаются документы, которыми обмениваются торговые роли, принимающие участие в сделке. Это хорошо сформатированный XML-документ. Документы, которые содержат сообщение, состоят из:
o блок ссылок транзакции, служащий для однозначной идентификации, частью которой является сообщение IOTP; o опционный блок Signature, который служит для цифровой подписи торговых блоков или компонентов, связанных с транзакцией IOTP; o опционный блок Error для уведомления о технических ошибках, содержащихся в предыдущем полученном сообщении IOTP и o последовательность торговых блоков IOTP, которые несут данные, необходимые для выполнения транзакции. |
| Транзакция IOTP | Транзакция IOTP (Internet Open Trading Protocol) представляет собой набор IOTP-сообщений, передаваемых торговыми ролями. Правила о том, что могут содержать IOTP-сообщения, определяются типом транзакции. |
| Тип транзакции IOTP | Тип транзакции идентифицирует ее разновидность. Примерами транзакции могут служить: покупка, возврат денег, аутентификация, отзыв, депозит. Типы транзакции IOTP определяет:
o торговые обмены, которые могут включаться в транзакцию; o то, как эти торговые обмены могут комбинироваться, чтобы обеспечить достижение цели транзакции; o какие торговые блоки могут быть включены в IOTP-сообщения, образующие транзакцию. |
| Продавец | Организация, которая предоставляет товары или услуги, и получает выгоду от платежей за них |
| Агент обслуживания Покупателя | Организация, которая вовлекается в диалог с покупателем от имени продавца с целью разрешения возникающих проблем |
| Организация | Компания или частное лицо, которое принимает участие в сделке и выполняет определенную торговую роль. Организации могут выполнять и несколько торговых ролей в одной сделке |
| Кассир | Организация, которая физически получает платеж от покупателя для продавца |
| Платежный инструмент | Платежный инструмент представляет собой средство, с помощью которого покупатель платит за товары или услуги, предлагаемые продавцом. Это может быть, например:
кредитная карта, такая как MasterCard или Visa;
>дебетная карта, такая как MasterCard's Maestro;
смарт-карта, базирующаяся на электронном платежном инструменте, таком как Mondex, GeldKarte или Visa Cash
электронный платежный счет, базирующийся на программе, такой как CyberCash's CyberCoin или DigiCash.
Все платежные инструменты имеют номер, обычно это номер счета, с помощью которого платежный инструмент может быть идентифицирован. |
| Льготный вид платежа | Льготный вид платежа предполагает, что, если покупатель воспользуется этим видом оплаты, тогда он получит дополнительную выгду, которая может быть реализована двумя путями:
в момент покупкиse. Например, если покупатель платит с помощью "Walmart MasterCard" на WEB-сайте Walmart, тогда он получает скидку 5%, а это означает, что покупатель в действительности заплатит меньше,
от эмитента платежного инструмента (карты), когда платеж появится в ведомости. Например, если сумма платежей с использованием данного платежного инструмента превысила некоторое значение.
В списке видов платежа, предлагаемом продавцом, каждый льготный вид должен идентифицироваться, как независимый. |
| Компонент Receipt (расписка) | Компонент Receipt является записью об успешном завершении торгового обмена. Примеры компонентов Receipt включают в себя: платежные расписки и накладные при доставке (Delivery Notes). Их содержимое зависит от технологии выполнения торгового обмена. Например, платежная расписка SET (Secure Electronic Transaction) состоит из платежных сообщений SET, которые фиксируют результат оплаты. |
| Блок запроса | Блок запроса является торговым блоком, который содержит запрос начала торгового обмена. Торговые компоненты в блоке запроса могут быть подписаны с помощью блока Signature, что позволит идентифицировать отправителя. Авторизация начала торгового обмена может быть выполнена с помощью подписей, содержащихся в компонентах Receipt, которые вложены в блоки откликов предыдущего торгового обмена. Примерами блоков запроса могут служить запросы платежа и запросы доставки |
| Блок отклика | Блок отклика является торговым блоком, который указывает, что торговый обмен завершился. Он посылается торговой ролью, которая получила блок запроса, торговой роли. Блок отклика содержит компонент Status с информацией о завершении торгового обмена, например, он указывает, завершился ли торговый обмен успешно. Для некоторых торговых обменов блок отклика содержит компонент Receipt (расписка). Компоненты Receipt могут цифровым образом подписывать сообщение с использованием блока Signature, что делает завершение торгового обмена неопровержимым. Примеры блоков отклика включают в себя отклики предложения, платежа и доставки. |
| Блок подписи | Блок подписи является торговым блоком, который содержит одну или более цифровых подписей в виде компонентов Signature. Компонент Signature может цифровым образом подписывать любой блок или компонент в любом сообщении IOTP |
| Компонент Status | Компонент Status содержит информацию, которая описывает состояние торгового обмена. До завершения торгового обмена компонент Status может указывать на то, как он проходит. Если же торговый обмен завершился, компонент Status может говорить лишь об успешном завершении или о наличии рабочей ошибки. Рабочая ошибка указывает, что продолжение торгового обмена невозможно, так как нарушено какое-то правило, например, "нет достаточных средств". При этом не предполагается каких-либо технических ошибок, связанных с содержимым или форматом IOTP-сообщения в транзакции. |
| Техническая ошибка | Смотри блок Error. |
| Торговый блок | Торговый блок состоит из одного или более торговых компронент. Один или более торговых блоков может содержаться в IOTP-сообщениях, которые пересылаются в форме XML-документов от одной торговой роли к другой. Сущетсвует три типа торговых блоков:
o блок Request, o блок Exchange или o блок Response |
| Торговый компонент | Торговый компонент является собранием XML-элементов и атрибутов. Торговые компоненты являются дочерними элементами Торговых блоков. Примерами торговых компонентов являются: Предложение, Список видов платежей, Платежная расписка, Доставка [информации], Сумма платежа |
| Торговый обмен |
Торговый обмен предполагает обмен последовательностью документов, пересылаемых между торговыми ролями. Документы могут иметь форму торговых блоков или они могут быть пересланы каким-то другим образом, например, путем ввода данных на WEB-странице. Каждый торговый обмен состоит из трех главных частей:
посылки блока запроса торговой ролью (инициатором) другой торговой роли (получателю);
опционного обмена одним или более блоков между инициатором и получателем до тех пор пока
торговая роль, которая получила блок запроса, не отправит блок отклика инициатору. Примерами торговых обменов/услуг могут служить: платеж, где покупатель осуществляет платеж кассиру; доставка, где покупатель запрашивает, и опционно получает, товар или услугу от агента доставки; аутентификация, где любая торговая роль может запросить и получить информацию о другой торговой роли; предложение, которое получает покупатель от продавца, имеет целью предложить какую-то торговую сделку (транзакцию). |
| Торговая роль | Торговая роль идентифицирует различные способы, которыми организации могут участвовать в сделке. Существует пять торговых ролей: Покупатель, Продавец, Кассир, Агент доставки и Агент обслуживания покупателя. |
| Блок ссылок транзакции | Блок ссылок транзакции идентифицирует транзакцию IOTP. Он содержит данные, которые идентифицируют:
тип транзакции;
транзакцию IOTP, снабжая ее уникальным идентификатором;
сообщение IOTP, снабжая его уникальным идентификатором.
Блок ссылок транзакции может также содержать ссылки на другие транзакции, которые, вообще говоря, могут и не быть транзакциями IOTP |
Соображения безопасности
5. Соображения безопасности
Здесь рассматриваются следующие проблемы:
| o | определение того, следует ли использовать электронную подпись; |
| o | конфиденциальность данных; |
| o | безопасность платежного протокола. |
5.1. Принятие решения о применении электронной подписи
Использование электронной подписи в IOTP является исключительно опционным. IOTP может успешно работать вообще без цифровых подписей.
В конце концов, использовать ли цифровую подпись, решает продавец или другая торговая роль, покупатель же решает обеспечивает ли приемлемый уровень риска вариан без электронной подписи. Если продавцы выяснят, что транзакции без подписей не приемлемы, то они имеют следующий выбор:
o начать использовать подписи,
o найти метод работы, где не требуются подписи или,
o выбрать более низкий объем и стоимость торговых операций.
Перечень некоторых причин использования цифровых подписей представлен ниже:
Продавец (или другая торгвая роль) хочет продемонстрировать, что ему можно верить. Если, например, продавец генерирует подпись отклина-предложения (смотри раздел 7.19.2), используя сертификат, полученный от третей стороны, известной покупателю, тогда покупатель может проверить подпись и сертификат, после чего он сможет с приемлемой достоверностью доверять тому, что предложение получено от означенной организации-продавца. В этом случае подписи используют асимметричную криптографию. Продавец, или другая торгвая роль, хочет сгенерировать запись транзакции, которая подходит для определенной цели. Например, с приемлемой достоверностью цифровые подписи могут быть использованы Покупателем, чтобы определить:| - будет ли сообщение принято налоговой службой, в качестве корректной записи транзакции; | ||
| - если нужна гарантия, например, от "Better Business Bureau" или подобной организации. |
Если запрос не подписан, покупатель может изменить сумму, например, удалив одну цифру. Если Кассир не имеет доступа к исходной платежной информации отклика-предложения, тогда в отсутствии подписи, кассир не может быть уверен, что данные не были модифицированы. Аналогичго, если платежная информация не подписана цифровым образом, кассир не может быть уверен, кто является продавцом, запросившим этот платеж. Кассир или агент доставки хочет предоставить неопровержимую запись совершения платежной операции или выполнения доставки. Если платежный отклик или отклик доставки подписан, тогда покупатель может позднее использовать запись о платеже или доставке, чтобы доказать, что она состоялась. Это может использоваться, например, для целей обслуживания покупателя. Ниже приводится список некоторых причин, почему электронная подпись может не использоваться:
Торговые роли иногда объединяются, следовательно изменения данных, выполненные покупателем могут быть обнаружены. Одной из причин использования подписи, это выявление того, что изменения внесены покупателем или другим партнером. Однако, если торговые роли имеют доступ к необходимым данным, то можно провести сравнение, нпример, информацию из платежного запроса и из отклика предложения. Доступ к данным может быть реализован, например, продавцом и кассиром, работающими в одной организации. Стоимость криптографии слишком велика. Например, если платеж составляет всего несколько центов, стоимость выполнения криптографических операций, сопряженных с генерацией и проверкой цифровой подписи делает последнюю экономически не целесообразной. 5.2. Симметричная и асимметричная криптография
Преимущество использования симметричных ключей заключается в искдючении инфраструктуры, сопряженной с обслуживанием открытых ключей. В этом случае Продавец, Кассир и Агент доставки должны договориться об использовании общего секретного ключа.
Однако неудобства симметричной криптографии заключается в том, что покупатель не может надежно идентифицировать Продавца, Кассира и Агента доставки с которыми он имеет дело.
Это существенно понижает доверие системе покупателя.
Однако следует заметить, что даже в случае использования асимметричной криптографии Покупатель не нуждается в цифровых сертификатах, так как целостность транзакции определяется кассиром, проверяющим подпись отклика предложения, скопированную с платежного запроса.
Заметим, что в одной транзакции может использоваться симметричная, асимметричная криптография или обе ее разновидности.
5.3. Конфиденциальность данных
Конфиденциальность информации обеспечивается путем пересылки IOTP-сообщений между торговыми ролями, используя секретный канал, такой как [SSL/TLS]. Использование безопасного канала в IOTP является опционным.
5.4. Безопасность платежного протокола
IOTP сконструирован так, чтобы быть нечувствительным к используемому платежному протоколу.
IOTP способствует безопасности, используя цифровые подписи для установления однозначного соответствия запроса и отклика и для аутентификации отправителя сообщений. Например IOTP связывает вместе: предложение, платеж и доставку.
Соображения IANA
12. Соображения IANA
12.1. Коды контролируемые IANA
Для того чтобы гарантировать совместимость, коды, используемые IOTP, нужно поддерживать в контролируемой среде так, что их значения и использование были строго определены, а дублирование кодов должно быть исключено. IANA представляет механизм решения этой проблемы, как это описано в RFC 2434.
Типы элементов и имена атрибутов, к которым эта процедура применяется, приведены ниже в таблице вместе с исходными величинами, разрешенными для этих атрибутов.
Заметим, что:
торговый подписной лист IETF имеет адрес "Специальные эксперты (Designated Experts)" (смотри [IANA]) назначаются IESG.| Тип элемента/Имя атрибута | Значения атрибутов |
| Алгоритм/Имя | "sha1" – указывает, что будет использована аутентификация [SHA1] |
| (Когда алгоритм является производным от компонента AuthReq) | "Подпись" – указывает, что аутентификация включает в себя генерацию цифровой подписи. |
| "Pay:ppp", где "ppp" может быть установлено равным любому допустимому значению для "iotpbrand" (смотри ниже) |
За исключением алгоритмов, которые начинаются с "pay:", новые значения выделяются после просмотра торгового почтового списка IETF и с привлечением “специального эксперта”.
Элемент Algorithm обычно определяется в пределах пространства имен [DSIG]. Со временем эта процедура может измениться.
Тип элемента/Имя атрибута |
Значения атрибутов |
| Вид платежа/BrandId | Следующий список исходных значений BrandId был получен от организаций, которые сипользуют сертификаты протокола SET с 1-го июня 1999: "Amex" - American Express "Dankort" – Dankort "JCB" – JCB "Maestro" – Maestro "MasterCard" – MasterCard "NICOS" – NICOS "VISA" - Visa Кроме того определены следующие значения Id видов платежа: "Mondex" "GeldKarte" |
Новые значения BrandId должны быть опубликованы через торговый подписной лист IETF и, если в течение трех недель не поступает возражений, они присваиваются в порядке поступления.
| Валютная сумма/CurrCode | Коды валюты зависят от CurrCodeType (смотри ниже). |
Если CurrCodeType = "IOTP", тогда новые значения должны быть опубликованы через торговый подписной лист IETF и, если в течение трех недель не поступает возражений, они присваиваются в порядке поступления.
Код типа валюты IOTP, сконструирован так, чтобы позволять поддержку "новых" псевдовалют, таких как loyalty или frequent flyer points. На момент написания этого документа ни один из таких кодов не был лпределен.
| Тип элемента/Имя атрибута | Значения атрибута |
| Валютная сумма/CurrCodeType | "ISO4217A" "IOTP" |
| DeliveryData/DelivMethod | "Post" "Web" "Email" |
| PackagedContent/Content | "PCDATA" "MIME" "MIME:mimetype" (где mimetype должен быть тем же, что и в content-type, как это определено в [MIME]) "XML" |
В противном случае, новые значения атрибута Content выделяются после публикования через подписной лист IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как используется новый атрибут в элементе Packaged Content.
| RelatedTo/RelationshipType | "IotpTransaction" "Reference" |
Это может потребовать публикации дополнительной документации, описывающей как осуществляется метод доставки.
| Тип элемента/Имя атрибута | Значения атрибута |
| Status/StatusType | Предложение Платеж Доставка Аутентификация Не идентифицировано Новые значения атрибута Status Type выделяются после: oпубликации в Торговой Рабочей Группе IETF, документа RFC, описывающего торговый обмен, торговые роли и соответствующие компоненты, которые относятся к Status и oрассмотрения документа в торговом почтовом листе IETF и экспертами. |
| TradingRole/TradingRole | "Consumer" "Merchant" "PaymentHandler" "DeliveryHandler" "DelivTo" oрассмотрения документа в торговом почтовом листе IETF и экспертами. |
| Тип элемента/Имя атрибута | Значения атрибута |
| TransId/IotpTransType | "BaselineAuthentication" "BaselineDeposit" "BaselineRefund" "BaselineWithdrawal" "BaselineValueExchange" "BaselineInquiry" "BaselinePing" Новые значения атрибута IotpTransType выделяются после: oпубликации через почтовый список IETF, в виде документа RFC, описывающего новую транзакцию IOTP и oрассмотрения документа в почтовом списке торговой рабочей группы IETF и экспертами. |
| Attribute/Content (смотри компонент Signature) |
"OfferResponse" "PaymentResponse" "DeliveryResponse" "AuthenticationRequest" "AuthenticationResponse" "PingRequest" "PingResponse" Новые значения кода, которые описывают тип подписи выделяются после: oпубликации в Торговой Рабочей Группе IETF документа RFC, описывающего торговый обмен, где используются подписи и oрассмотрения документа в торговом почтовом листе IETF и экспертами. |
Документ, описывающий новые значения типа подписи, может быть объединен с документами, описывающими новые типы Status и торговые роли (смотри выше).
12.2. Коды, неконтролируемые IANA
Помимо формального выбора и регистрации кодов, как это описано выше, для разработчиков существует необходимость экспериментировать с новыми кодами IOTP. По этой причине могут использоваться "коды определенные пользователем", что не требует регистрациив IANA. Определение кода, задаваемого пользователем, выглядит следующим образом:
user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*
| NameChar | NameChar имеет то же определение, что и [XML] определение NameChar. |
Список видов атак, зарегистрированных Network ICE
6.3.1 Список видов атак, зарегистрированных Network ICE
Число официально зарегистрированных в мире сетевых инцидентов различного рода возрастает экспоненциально, о чем можно судить по Рисунок 1. (см. http://www.cert.org/stats/). Этот рост совпадает с ростом числа узлов в интернет, так что процент хулиганов и шизефреников величина похоже инвариантная. Атаки можно разделить на несколько классов:
Базирующиеся на дефектах протоколов, например, TCP. Использующие дефекты операционной системы Пытающиеся найти и воспользоваться дефектами программ-приложений, включая, например, CGI Эксплуатирующие человеческие слабости (любопытство, алчность и пр., например, троянские кони)Список номеров портов для известных троянских коней можно найти в
К первому типу относятся и атаки типа SMURF, ICMP flood и TCP SYN flood. ICMP flood не использует эффектов усиления на локальных широковещательных адресах, а работает c адресами типа 255.255.255.255. Здесь следует заметить, что для аналогичных целей хакеры могут использовать и протоколы TCP или UDP.
Ссылки
15. Ссылки
| [Base64] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. |
| [DOM-HASH] | Maruyama, H., Tamura, K. and N. Uramoto, "Digest Values for DOM (DOMHASH)", RFC 2803, April 2000. |
| [DNS] | Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. |
| [DNS] | Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. |
| [DSA] | The Digital Signature Algorithm (DSA) published by the National Institute of Standards and Technology (NIST) in the Digital Signature Standard (DSS), which is a part of the US government's Capstone project. |
| [ECCDSA] | Elliptic Curve Cryptosystems Digital Signature Algorithm (ECCDSA). Elliptic curve cryptosystems are analogues of public-key cryptosystems such as RSA in which modular multiplication is replaced by the elliptic curve addition operation. See: V. S. Miller. Use of elliptic curves in cryptography. In Advances in Cryptology - Crypto '85, pages 417-426, Springer-Verlag, 1986. |
| [HMAC] | Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. |
| [HTML] | Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995. |
| [HTML] | Hyper Text Mark Up Language. The Hypertext Mark-up Language (HTML) is a simple mark-up language used to create hypertext documents that are platform independent. See the World Wide Web (W3C) consortium web site at: http://www.w3.org/MarkUp/ |
| [HTTP] | Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC-1945, May 1996. |
| [HTTP] | Fielding, R., Gettys, J., Mogul, J., Frystyk, T. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1.", RFC-2616, June 1999. |
| [IANA] | The Internet Assigned Numbers Authority. The organisation responsible for co-ordinating the names and numbers associated with the Internet. See http://www.iana.org/ |
| [ISO4217] | ISO 4217: Codes for the Representation of Currencies. Available from ANSI or ISO. |
| [IOTPDSIG] | Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC-2802, April 2000. |
| [MD5] | Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, April 1992. |
| [MIME] | Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. |
| [MIME] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC-2045, November 1996. |
| [MIME] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC-2046, November 1996. |
| [MIME] | Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text" RFC-2047, November 1996. |
| [MIME] | Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC-2048, November 1996. |
| [MIME] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples" RFC-2049, November 1996. |
| [OPS] | Open Profiling Standard. A proposed standard which provides a framework with built-in privacy safeguards for the trusted exchange of profile information between individuals and web sites. Being developed by Netscape and Microsoft amongst others. |
| [RFC1738] | Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC-1738, December 1994. |
| [RFC2434] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC-2434, October 1998. |
| [RSA] | RSA is a public-key cryptosystem for both encryption and authentication supported by RSA Data Security Inc. See: R. L. Rivest, A. Shamir, and L.M. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2): 120-126, February 1978. |
| [SCCD] | Secure Channel Credit Debit. A method of conducting a credit or debit card payment where unauthorised access to account information is prevented through use of secure channel transport mechanisms such as SSL/TLS. An IOTP supplement describing how SCCD works is under development. |
| [SET] | Secure Electronic Transaction Specification, Version 1.0, May 31, 1997. Supports credit and debit card payments using certificates at the Consumer and Merchant to help ensure authenticity. Download from: <http://www.setco.org>. |
| [SSL/TLS] | Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC-2246, January 1999. |
| [SHA1] | [FIPS-180-1]"Secure Hash Standard", National Institute of Standards and Technology, US Department Of Commerce, April 1995. Also known as: 59 Fed Reg. 35317 (1994). See http://www.itl.nist.gov/div897/pubs/fip180-1.htm |
| [UTC] | Universal Time Co-ordinated. A method of defining time absolutely relative to Greenwich Mean Time (GMT). Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" where the "+n" defines the number of hours from GMT. See ISO DIS8601. |
| [UTF16] | The Unicode Standard, Version 2.0. The Unicode Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 Proposed Draft Amendment 1 |
| [X.509] | ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, Including Draft Amendment 1: Certificate Extensions (Version 3 Certificate) |
| [XML | Recommendation for Namespaces in XML, World Wide Web Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC-xml-names" |
| [XML] | Extensible Mark Up Language. A W3C recommendation. See http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 version. |
Ссылки элемента (Element References)
Рисунок .9. Ссылки элемента (Element References)
Атрибуты ссылки элемента определены как "NMTOKEN", а не "IDREF" (смотри [XML]). Это сделано потому, что IDREF требует, чтобы элемент XML, на который ссылаются, принадлежал тому же XML-документу. В IOTP это не всегда так.
3.6. Расширение IOTP
Базовая версия IOTP определяет минимальный протокол, с которым система, поддерживающая IOTP, должна быть способна работать. По мере разработки новых версий IOTP будут определяться дополнительные типы транзакций IOTP. Кроме того, базовая и будущие версии IOTP будут поддерживать два механизма расширения возможностей IOTP пользователем:
o дополнительные XML-элементы
o новые значения существующих IOTP-кодов.
3.6.1. Дополнительные XML-элементы
Имена XML элементов и атрибутов используемых в IOTP составляют пространство имен [XML], как это определено атрибутом xmlns элемента IotpMessage. Это позволяет Th IOTP поддерживать включение дополнительных XML-элементов в IOTP-сообщения посредством использования пространства имен XML. Используя XML Namespaces, дополнительные XML-элементы могут быть включены на любом уровне в сообщение IOTP, включая:
o новые торговые блоки
o new торговые компоненты
o новые XML-элементы торгового компонета.
При этом следуют определенным правилам:
| о | Любой новый XML-элемент должен быть декларирован согласно правилам [XML Namespaces] |
| o | Новые XML-элементы, которые являются торговыми блоками или компонентами должны содержать ID-атрибуты с именем атрибута ID. |
Для того чтобы быть уверенным, что дополнительные элементы XML могут быть обработаны корректно, IOTP резервирует использование специального атрибута, IOTP:Critical, который принимает значение True или False и может появляться в дополнительных элементах, добавляемых к IOTP-сообщению. Целью этого атрибута является допущение IOTP проинформировать приложение, можно ли безопасно продолжить транзакцию. В частности:
Если дополнительный XML-элемент имеет атрибут "IOTP:Critical" со значением "True" и IOTP уведомлен приложением, что оно не знает как обрабатывать элемент и его дочерние элементы, тогда транзакция IOTP выдает техническую ошибку (смотри раздел 4.1). Если дополнительный XML-элемент имеет атрибут "IOTP:Critical" со значением "False", тогда транзакция IOTP может продолжать работу, если IOTP уведомлен о том, что приложение не знает как обработать этот элемент.В этом случае:
| - любые дополнительные XML-элементы, содержащиеся в XML-элементе и определенные в пространтстве имен IOTP, должны включать этот элемен всякий раз, когда IOTP XML- элемен используется или копируется IOTP. | |
| - содержимое дополнительного элемента следует игнорировать, за исключением случая, когда оно должно учитываться при генерации дайджеста в ходе формировании электронной подписи. |
| IOTP:Critical | (True | False ) 'True' |
Если IOTP должен быть расширен с помощью Opaque Embedded Data, тогда к инкапсулированным данным должен быть применен элемент Packaged Content (смотри раздел 3.7).
3.7. Элемент PackagedContent
Элемент PackagedContent поддерживает концепцию потока вложенных данных, преобразованную, чтобы защитититься от неверной интепретации транспортной системой и гарантировать совместимость с XML. Примеры использования этого элемента в IOTP включают:
o для инкапсуляции сообщений платежной системы, таких как сообщения SET,
o для инкапсуляции описания заказа, чека (payment note) или накладной (delivery note).
В общем, он используется для инкапсуляции одного или более потоков данных. Этот поток данных имеет три стандартизованных атрибута, которые служат для идентификации, декодирования и интерпретации содержимого. Его определение представлено ниже.
<!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent Name CDATA #IMPLIED Content NMTOKEN "PCDATA" Transform (NONE|BASE64) "NONE" >
Атрибуты:
| Name | Опционно. Позволяет разделить случаи множественного применения элементов PackagedContent в одной и той же точке IOTP. Например: |
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
<PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45
</PackagedContent>
</ABCD>
Атрибут имени может быть опущен, например, если имеется только один элемент PackagedContent.
| Content | Идентифицирует, какой тип данных находится в содержимом элемента PackagedContent. Корректными значениями атрибута Content являются: |
| о | PCDATA. Содержимое элемента PackagedContent может рассматриваться как PCDATA и более не обрабатываться. |
| о | MIME. Содержимое элемента PackagedContent является MIME-объектом. Обработка должна включать поиск MIME-заголовков внутри элемента PackagedContent. |
| о | MIME:mimetype. Содержимое элемента PackagedContent является MIME-объектом с заголовком "Content-Type: mimetype". Хотя допускается иметь MIME:mimetype с атрибутом Transform равным NONE, более желательно иметь атрибут Transform равным BASE64. Заметим, что, если используется Transform = NONE, тогда все содержимое должно соответствовать PCDATA. Некоторые символы будет нужно закодировать как объекты XML, или как символьные объекты. |
| о | XML. Содержимое элемента PackagedContent может рассматриваться как XML-документ. Следует использвать секции CDATA, или Transform = BASE64, чтобы гарантировать, что содержимое элемента PackagedContent соответствует PCDATA. |
| Transform | Идентифицирует преобразование, которое было произведено нс даннвми, прежде чем они были помещены элемент. Допустимыми значениями являются: |
| PCDATA | Это действительные данные, которые вложены в элемент. Формат данных и правила их кодирования записаны в атрибутах Content и Transform. |
PackagedContent может содержать HTML. В этом случае должны выполняться следующие условия:
Ссылки на любой документы, изображения или другие вещи, такие как звук или WEB-страницы, могут влиять на понимание данных получателем, которые должны соотноситься с другими элементами Packaged, содержащимися в том же родительском элементе, например, описание заказа. Если, для того чтобы удовлетворить рассмотренным выше требованиям, в исходный элемент включен более чем один элемент PackagedContent, тогда атрибут Name верхнего уровня, который определяет ссылки на все другие элементы Packaged, должен иметь значение Main. Относительные ссылки на другие документы, изображения и т.д. одного элемента PackagedContent на другой реализуются путем установления значения относительной ссылки на атрибут Name другого элемента PackagedContent на том же уровне и в пределах того же родительского элемента. Никакие внешние ссылки, которые требуют немедленного разрешения, не должны быть использованы. Так как это может осложнить или сделать невозможным отображение HTML. [MIME] используется, чтобы инкапсулировать данные в пределах каждого элемента Packaged. Это означает, что информация в заголовке MIME использована для идентификации типа данных, которые инкапсулированы. Если выше приведенные соглашения не реализуются, например, включением внешних ссылок, которые должны быть разрешены, тогда получатель HTML должен быть об этом проинформирован.
В качестве руководства разработчику следует иметь в виду, что значения атрибутов Name, относящиеся к элементам PackagedContent, должны допускать извлечение каждого PackagedContent в каталог и отображение HTML непосредственно.
3.7.2. Пакетирование XML
Рекомендуется поддержка XML. Когда необходимо отобразить XML, например, чтобы представить содержимое описания заказа Покупателю, разработчики должны следовать новейшим рекомендациям консорциума World Wide Web.
3.8. Идентификация языков
IOTP использует идентификацию языка [XML] для того, чтобы специфицировать, какие языки применены в тексте и атрибутах IOTP-сообщения.
Для того чтобы определить, какие элементы XML содержат атрибуты xml:lang, нужно придерживаться следующих принципов:
обязательный атрибут xml:lang содержится в каждом торговом компоненте, где присутствуют атрибуты или содержимое, которое требует отображения или печати на определенном языке; опционный атрибут xml:lang вводится в дочерние элементы торговых компонентов. В этом случае значение xml:lang, если оно имеется, переписывает значение для торгового компонента. Атрибуты xml:lang, которые следуют этим принципам, включаются в торговые элементы, а их дочерние XML-элементы определены в разделе 7.
Отправитель сообщения, обычно Покупатель, может указать свои предпочтения для языка и символьного набора путем спецификации соответствующего списка в Id-компоненте сообщения (смотри раздел 3.3.2). Заметим, что получатель такого сообщения не обязан строго следовать этим предпочтениям, так как он может не иметь необходимых средств для этого. Это также означает, что возможность работать с этими списками не является требованием данной спецификации. Однако возможность реагировать, используя один из объявленных языков или символьных наборов является желательной.
3.9. Безопасные и небезопасные позиции в сети
IOTP содержит несколько "сетевых позиций", которые определяют место, куда молгут быть посланы сообщения IOTP-сообщения. Сетевые позиции (Net Locations) бывают двух типов:
"Безопасные" сетевые позиции, где конфиденциальность данных гарантируется с помощью, например, некоторых методов шифрования, таких как [SSL/TLS]. "Небезопасные" сетевые позиции, где конфиденциальность данных не гарантируется. Заметим, что должны присутствовать безопасная или небезопасная сетевая позиция (Net Location) или обе обязательно.
Если присутствует одна из двух сетевых позиций, только она и может использоваться.
Там где представлены оба типа сетевых позиций, допускается использование обоих, в зависимости от предпочтения отправителя сообщения.
3.10. Аннулированные транзакции
Любая торговая роль, вовлеченная в транзакцию IOTP может аннулировать эту транзакцию в любой момент.
3.10.1. Аннулирование транзакций
Транзакции IOTP аннулируются путем посылки сообщения IOTP, содержащего блок Cancel с соответствующим компонентом Status, другой торговой роли, вовлеченной в торговый обмен.
Блок Cancel может быть послан асинхронно по отношению к любому другому сообщению IOTP. В частности он может быть послан до посылки или после получения сообщения от другой торговой роли.
Если транзакция IOTP аннулирована во время торгового обмена (т.e. интервал между отправкой блока "запрос" и получением соответствующего ему блока "отклик"), тогда блок Cancel посылается тому же адресату, что и следующее сообщение IOTP в торговом обмене.
Если покупатель аннулирует транзакцию после завершения торгового обмена (т.e. блок "отклик" торгового обмена уже получен), но до завершения тразакции IOTP, покупатель посылает блок Cancel с соттветствующим компонентом Status сетевой позиции, идентифицированной SenderNetLocn или SecureSenderNetLocn, содержащимся в компоненте опции протокола (смотри раздел 7.1), который размещен в блоке TPO (смотри раздел 8.1). Это обычно торговая роль Продавца.
Покупатель не должен посылать блок Cancel после того как завершилась транзакция IOTP. Аннулирование всей транзакции будет рассматриваться как техническая ошибка.
После аннулирования транзакции IOTP, Покупатель должен обратиться в сетевую позицию, специфицированную атрибутом CancelNetLocn, содержащимся в элементе торговой роли для организации, которой был послан блок Cancel. Торговые роли, отличные от Покупателя, могут аннулировать транзакцию в следующих случаях:
| о | после получения блока запроса; |
| o | до посылки блока отклика. |
3.10.2. Обработка аннулированных транзакций
Если блок Cancel получен Покупателем в момент, когда аннулирование разрешено, тогда покупатель должен прервать транзакцию.
Если блок Cancel получен торговой ролью, отличной от Покупателя, тогда торговой роли следует ожидать, что Покупатель обратится к сетевойму узлу, специфицированному атрибутом CancelNetLocn, содержащимся в элементе Trading Role.
Структура адресов DSAP и SSAP
Рисунок 4.1.1.3.6. Структура адресов DSAP и SSAP
Поле CNTL может иметь длину 1 или 2 байта, а его структура соответствовать I, S или U-форматам (см. разделы и ). В однобайтовых полях DSAP и SSAP записывается код типа протокола сетевого уровня. Для протоколов IPX/SPX это и последующее поле содержат код 0xE0. Поле CNTL=03 обозначает нечисловой формат для уровня ethernet 802.2. Эти три байта часто представляют собой код производителя, как правило, совпадающий с первыми тремя байтами адреса отправителя. Иногда они просто делаются равными нулю. Поле тип (2 байта) характеризует используемую версию Ethernet. Из рисунка 4.1.1.3.5 видно, что первые два поля (адреса получателя и отправителя) и последнее поле (CRC) во всех форматах идентичны. При расчете CRC содержимое кадра рассматривается как двоичный полином. Производится деление этого кода на специальный образующий полином. Полученный остаток от деления дополняется по модулю один, результирующий код и считается контрольной суммой CRC. В поле адрес получателя может быть записан код 0xffffffffffff, что указывает на широковещательную адресацию кадра. Адрес отправителя такой код содержать не может. Третье поле может служить для выявления типа используемого протокола. Если в этом поле содержится число более 1500 (десятичное), это указывает на то, что данный кадр имеет формат Ethernet II, а само поле содержит не длину кадра а тип данных. Теперь, надеюсь, читателю понятно, почему кадр Ethernet 802.3 не может содержать более 1500 байт.
Кадр Ethernet 802.2 помимо первых трех полей содержит дополнительные три однобайтовые поля, следующие вслед за ними (DSAP, SSAP и CNTL). Кадр Ethernet SNAP является модификацией кадра Ethernet 802.2. Для этого кадра коды полей dsap и ssap равны 0xAA (признак кадра Ethernet SNAP), код CNTL=03 (нечисловой формат), поле код организации
(3 байта, характеризует организацию сети) равен нулю (для IPX/SPX), а двухбайтовое поле тип характеризует протокол высокого уровня. Для протоколов IPX/SPX в этом поле должен быть записан код 0x8138 (для ip - 0x0800, для arp - 0x0806, для rarp - 0x8035, а для Apple Talk - 0x809b).
Структура IP-адресов (NetID = идентификатор сети)
Рисунок 4.1.1.3.2. Структура IP-адресов (NetID = идентификатор сети)
Для удобства чтения IP-адреса обычно записываются в десятично-точечной нотации, например: 192.148.166.129 (адрес класса C).
Классу A соответствует диапазон адресов 1.0.0.0 - 127.255.255.255.
Классу B соответствует диапазон адресов 128.0.0.0 - 191.255.255.255.
Классу С соответствует диапазон адресов 192.0.0.0 - 223.255.255.255.
Классу D соответствует диапазон адресов 224.0.0.0 - 239.255.255.255.
Классу E соответствует диапазон адресов 240.0.0.0 - 247.255.255.255.
Ряд адресов является выделенными для специальных целей:
0.0.0.0 - обращение к ЭВМ, на которой производится работа;
255.255.255.255 - обращение ко всем машинам локальной сети.
127.xxx.xxx.xxx - помещение пакета во входной поток данной ЭВМ (loopback).
Два другие специальные адреса показаны на Рисунок 4.1.1.3.2.а.
Структура протокола
3. Структура протокола
В предыдущем разделе дано введение, которое объясняет:
Торговые роли, которые выполняют различные организации в ходе реализации сделки: Продавец, Покупатель, Кассир, Агент доставки и Агент обслуживания покупателя. Торговые обмены, каждый из которых предполагает некоторый информационный обмен между торговыми ролями в форме набора торговых компонентов.Ниже описано:
Как торговые компоненты формируются в торговые блоки и сообщения IOTP, которыми осуществляется обмен в форме XML-документов между различными торговыми ролями. Как производится обмен IOTP-сообщениями между торговыми ролями для того, чтобы выполнить операцию IOTP. XML-определения сообщений IOTP, включая операционный блок ссылки (Transaction Reference Block), - XML-элемент, который идентифицирует IOTP-операцию и IOTP-сообщение Message, сопряженное с ним. Определения ID-атрибутов XML, которые используются для идентификации сообщений IOTP, торговых блоков и компонентов, а также то, как они соотносятся с использованием элементов ссылок из других XML-элементов. Как дополнительные XML-элементы и новые определенные пользователем значения для существующих IOTP-кодов могут использоваться при расширении IOTP. Как IOTP использует элемент Packaged Content для вложения данных, таких как сообщения платежных протоколов или определения заказа, в сообщения IOTP. Как IOTP идентифицирует языки, чтобы можно было использовать различные языки в рамках сообщений IOTP. Как IOTP работает с безопасными и опасными сетевыми позициями (Net Locations), при посылке сообщений. Как могут аннулироваться операции IOTP.3.1. Обзор
3.1.1. Структура сообщений IOTP
Структура сообщения IOTP и его отношения с торговыми блоками и компонентами проиллюстрировано на диаграмме ниже.
Структура сообщения IOTP
Рисунок .6. Структура сообщения IOTP
На диаграмме определена концепция блока ссылок операции (Transaction Reference Block). Такой блок содержит среди прочего уникальный идентификатор операции IOTP. Кроме того, каждому блоку и компоненту присваивается ID-атрибут (смотри раздел 3.4), который является уникальным в пределах IOTP. Следовательно, комбинации ID-атрибута и глобального уникального идентификатора в блоке ссылок операции достаточно, для однозначной идентификации любого торгового блока или компонента.
3.1.2. Операции IOTP
Предопределенный набор сообщений IOTP, которыми обмениваются торговые роли, составляют операцию IOTP. Это проиллюстрировано ниже на диаграмме.
Характеристики классов адресов
Таблица. 4.1.1.3.1 Характеристики классов адресов
| Класс адреса | Диапазон значений первого октета | Возможное количество сетей | Возможное количество узлов |
| A | 001 ... 126 | 128 | 16777214 |
| B | 128 ... 191 | 16382 | 65534 |
| C | 192 ... 223 | 2097150 | 254 |
| D | 224 ... 239 | 228 | |
| E | 240 ... 247 | 227 |
Структура ip-адресов изображена на рисунке 4.1.1.3.2:
кодов протоколов приведена
Таблица кодов протоколов приведена в приложении (см. также RFC-1700). Поля тип протокола и по смыслу и по содержанию идентичны для всех разновидностей кадра Ethernet (кроме ieee 802.3).
Транспортный уровень должен воспринимать данные от нескольких пользовательских программ и пересылать их на более низкий уровень. Многоуровневые протоколы спроектированы так, чтобы слой N по месту назначения получал ту же самую информацию, что была послана слоем N отправителя. Прикладные программы также как и все протокольное программное обеспечение уровня Интернет и выше использует только IP-адреса (32 бита), в то время как уровень сетевого программного обеспечения работает с физическими сетевыми адресами (так Ethernet использует 48-битные адреса).
Когда IP-дейтограмма попадает в ЭВМ, сетевое программное обеспечение передает ее программе IP-уровня. Если адрес места назначения совпадает с IP-адресом ЭВМ, дейтограмма принимается и передается на более высокий уровень для дальнейшей обработки. При несовпадении адресов дейтограмма уничтожается (переадресация дейтограмм для ЭВМ запрещена, это функция маршрутизатора). Хотя можно заставить ЭВМ выполнять задачи маршрутизации, с точки зрения Интернет-философии это плохая идея.
Различные сети и каналы имеют разные скорости обмена и надежность передачи. Это определяет длину пакета, пересылка которого с высокой вероятностью будет осуществлена без ошибки. Так как Интернет объединяет самые разные узлы и сети, использующие разные длины посылок, при реализации связи между такими объектами размер пакета задается наименее надежным узлом и длина пакета выбирается минимальной из двух. Поэтому при передаче длинного пакета через такой участок сети он сегментируется и передается по частям. Размер фрагмента определяется величиной максимального передаваемого блока (MTU - maximum transfer unit, в Ethernet MTU=1500 октетам). Величины MTU для других сред приведены в таблице 4.1.1.3.2:
Общепринятые сокращения, используемые при диалоге
Таблица 4.5.15.1. Общепринятые сокращения, используемые при диалоге
| Общепринятое сокращение выражения | Выражение | Перевод |
| BCNU | be seeing you | пока |
| BRB | be right back | возвращайся вовремя |
| BTW | by the way | кстати |
| BYE | goodbye | до свидания, я готов закончить диалог |
| BYE? | Goodbye? | вы готовы завершить диалог? |
| CU | see you | пока |
| CUL | see you later | увидимся |
| FYI | for your information | для вашего сведения |
| FWIW | for what it's worth | за чем это нужно |
| GA | go ahead and type | давай, продолжай |
| IMHO | in my humble opinion | по моему скромному мнению |
| IMO | in my opinion | по моему мнению |
| JAM | just a minute | минутку |
| O | over | ваша очередь говорить |
| OO | over and out | до свидания |
| OBTW | oh, by the way | а кстати |
| ROTFL | rolling on the floor laughing | кататься по полу от смеха |
| R U THERE? | are you there? | вы там? |
| SEC.. | wait a second | подождите секунду |
| WRT | with respect to | с уважением |
IRC - (Internet Relay Chat, RFC-1459) представляет собой систему переговоров в реальном времени. Она аналогична команде talk, которая используется на многих ЭВМ в Интернет. IRC делает все, что может talk, но позволяет также переговариваться более чем двум лицам одновременно. IRC предоставляет и много других удобных услуг.
Когда вы печатаете текст в IRC, все что вы напечатали будет немедленно передано другим пользователям, кто подключен к разговору. Причем они при желании могут вам ответить в реальном масштабе времени. Темы обсуждений в IRC варьируются в широких пределах. Обычно разговор идет по-английски, но существуют каналы для немецкого, японского, финского и других языков (русский язык здесь не является исключением, какой-же русский откажет себе в удовольствии поболтать, особенно в рабочее время). Клиенты и серверы для IRC доступны через анонимное FTP по адресу: . Некоторые узлы позволяют доступ к IRC через telnet, например, wbrt.wb.psu.edu и irc.demon.co.uk. В обоих узлах вход в систему осуществляется (login) как IRC.
В таблице 4.5.15.2 приведены основные команды IRC.
Основные команды IRC
Таблица 4.5.15.2. Основные команды IRC
| Команда IRC | Описание |
| /a | Отбрасывание оставшегося выхода для текущей команды |
| /help | Отобразить список IRC-команд |
| /help команда | Выдает описание команды |
| /help intro | Отображает введение в IRC |
| /help newuser | Отображает информацию о новых пользователях |
| /join канал | Подключиться к соответствующему каналу |
| /leave канал | Покинуть соответствующий канал |
| /list | Выдать информацию о всех каналах. |
| /list канал | Отобразить информацию о конкретном канале |
| /list -min n | Отобразить каналы, которые имеют как минимум n человек |
| /list –max n | Отобразить каналы, в которых не более n человек |
| /me операция | Отобразить определенную операцию |
| /mode * +p | Делает текущий канал личным |
| /msg псевдоним текст | Посылка частного сообщения указанному человеку |
| /msg , текст | Посылка сообщения последнему корреспонденту, кто вам что-то прислал |
| /msg . текст | Посылка сообщения последнему корреспонденту |
| /nick | Отобразить ваш псевдоним |
| /nick псевдоним | Изменить ваш псевдоним |
| /query псевдонимы | Послать все ваши сообщения указанным лицам |
| /query | Прекратить посылку частных сообщений |
| /quit | Прервать работу IRC (quit). |
| /set novice off | Позволить некоторые операции, например, подключение ко многим каналам |
| /who канал | Определяет, кто подключен к определенному каналу |
| /who псевдоним | Выдает информацию о конкретном человеке |
| /who * | Определяет, кто подключен к каналу |
| /whois псевдоним | Выдает всю информацию об определенном человеке |
| /whois * | Выдает всю информацию о всех |
Многие серверы системы IRC для соединения друг с другом используют древовидную схему. Некоторые серверы, взаимодействуя друг с другом, передают информацию о существовании других серверов, пользователей или других ресурсов. Фундаментальной для IRC является концепция канала. Все пользователи, когда они в системе IRC, находятся на одном канале. Сначала вы входите в нулевой канал. Вы не можете послать сообщение, пока вы не вошли в канал и не задали параметры этого канала.
Число каналов не ограничено.
Когда вы находитесь в системе IRC и нуждаетесь в помощи, выдайте команду /help. При возникновении проблем можно контактировать с Кристофером Девисом (Christopher Davis, ckd@eff.org) или с Еленой Роуз (Helen Rose, hrose@eff.org). Можно запросить помощь у оператора каналов IRC, например, #twilight_zone и #eu-opers. Различные документы по IRC и архивы списков рассылки IRC доступны через анонимное FTP по адресу , cs.bu.edu irc/support/alt-irc-faq или dorm.rutgers.edu pub/Internet.documents/irc.basic.guide. Группа новостей:
alt.irc, alt.irc.recovery. Имеется возможность доступа к материалам по IRC и через WWW: ; eru.dd.chalmers.se home/f88jl/Irc; mistral.enst.fr ~pioch/IRC; alpha.acast.nova.edu IRC; cgi-bin/www2irc.
RELAY
RELAY представляет собой систему серверов в глобальной сети Bitnet/EARN, которая ретранслирует интерактивные сообщения от одного пользователя к другим, кто подписан на данный "канал" системы RELAY. Пользователь, подписанный на ближайший RELAY, виртуально подписан на всю систему RELAY. Большинство узлов RELAY отключаются в часы пик. Только некоторые из них работают 24 часа в сутки. Каждый RELAY-сервер обслуживает ограниченное число узлов, называемых сферой обслуживания. RELAY - это программа, которая позволяет нескольким людям общаться через сеть в реальном масштабе времени. Для того чтобы начать, вы должны подписаться на RELAY, для чего поместить ваш ID в текущий список пользователей. Взаимодействие с RELAY осуществляется также, как с обычным пользователем. Команды RELAY начинаются с символа /, все что не начинается с / считается сообщением и пересылается всем текущим пользователям.
RELAY доступна по следующим адресам EARN/Bitnet. В скобках приведено условное имя RELAY-ЭВМ.
| RELAY@AUVM (Wash_DC) | RELAY@PURCCVM (Purdue) |
| RELAY@BEARN (Belgium) | RELAY@SEARN (Stockholm) |
| RELAY@ITESMVF1 (Mexico) | RELAY@TAUNIVM (Israel) |
| RELAY@CEARN (Geneva) | RELAY@TECMTYVM (Monterrey) |
| RELAY@CZHRZU1A (Zurich) | MASRELAY@UBVM (Buffalo) |
| RELAY@DEARN (Germany) | RELAY@UFRJ (RioJaneiro) |
| RELAY@DKTC11 (Copenhagen) | RELAY@UIUCVMD (Urbana_IL) |
| RELAY@FINHUTC (Finland) | RELAY@USCVM (LosAngeles) |
| RELAY@GITVM1 (Atlanta) | RELAY@UTCVM (Tennessee) |
| RELAY@GREARN (Hellas) | RELAY@UWAVM (Seattle) |
| RELAY@HEARN (Holland) | RELAY@VILLVM (Philadelph) |
| RELAY@JPNSUT00 (Tokyo) | RELAY@YALEVM (Yele) |
| RELAY@NDSUVM1 (No_Dakota) | RELAY@WATDCS (Waterloo) |
При регистрации клиенту посылаются файлы RELAY INFO и RELAY USERGUIDE, которые содержат подробное описание RELAY.
Краткое руководство по применению RELAY доступно из списка файлов документов EARN. Пошлите e-mail по адресу LISTSERV@EARNCC.BITNET. В теле сообщения напечатайте: GET RELAY MEMO.
стандартизованных имен
Таблица стандартизованных имен приведена в приложении . Преобразование символьного имени в IP-адрес производится в DNS-сервере узла, который представляет собой базу данных с удаленным доступом. Если искомое имя узла в локальном DNS-сервере отсутствует, он может прислать в качестве ответа адрес другого DNS-сервера, куда следует обратиться, чтобы определить IP-адрес искомого узла. Анализ имени обычно производится справа налево. Более подробно DNS-система описана в документах RFC-822, -823, а также ниже в разделе DNS. О правилах получения IP-адресов и регистрации имен сетей можно прочесть в .
При формировании пакетов различного уровня используется принцип инкапсуляции (вложения). Так IP-пакеты вкладываются в Ethernet-пакеты (кадры). Всякий пакет имеет заголовок и тело, некоторые из них снабжены контрольной суммой. Схема такого вложения представлена на рисунках 4.1.1.3.4 и 4.1.1.3.5.
Поле тип определяет используемый в дейтограмме протокол, PAD - пустые биты, дополняющие размер дейтограммы до 48 бит. В случае протокола IEEE 802.3 полю тип (>150010) соответствует поле длина (
Пакетный принцип позволяет передавать информацию от разных источников к различным адресатам по общему телекоммуникационному каналу. Схема вложения пакетов в рамках TCP/IP показана на Рисунок 4.1.1.3.4.
Принцип вложения (также как и фрагментации) является фундаментальным для любых современных сетей. Этот принцип используется в сетях netware, Apple Talk, TCP/IP т.д.
Значения mtu для различных сетевых стандартов
Таблица 4.1.1.3.2 Значения mtu для различных сетевых стандартов
Сеть |
MTU (байт) |
| hyperchannel (Сеть с топологией типа шина, с csma/cd-доступом, числом подключений < 256, максимальной длиной сети около 3,5км (93-омный коаксиальный кабель rg59 или оптоволокно)) | 65535 |
| 16 Мбит/с маркерное кольцо (ibm) | 17914 |
| 4 Мбит/с маркерное кольцо (ieee 802.5) | 4464 |
| fddi | 4352 |
| Ethernet II | 1500 |
| IEEE 802.3/802.2 | 1492 |
| x.25 | 576 |
| point-to-point (при малой задержке) | 296 |
Рассмотрим по фрагментную передачу дейтограммы с длиной в 1300 октетов в предположении, что более 576 октетов за один раз передать нельзя.
Торговые блоки
8. Торговые блоки
Торговые блоки являются дочерними элементами IOTP-сообщения верхнего уровня, которое послано в форме [XML]-документа от одного партнера торговой операции к другому.
Каждый трговый блок состоит из одного или более торговых компонентов (смотри раздел 7). Это проиллюстрировано на диаграмме.
Блок TPO должен содержать:
компонент протокольных опций; компонент Organisation с торговой ролью Продавца; компонент Organisation с торговой ролью Покупателя; опционно, компонент организации торговой ролью DeliverTo, если транзакция предполагает доставку; компоненты списка видов платежа для каждого платежа транзакции; компоненты Organisation для Кассира, включенного в транзакцию; опционно, компоненты Organisation для Агента доставки (если имеется) транзакции; дополнительные компоненты Organisation, которые Продавец захочет включить. Например.
| - Агент обслуживания Покупателя; | |
| - источник сертификатов, который предлагает "коды доверия (Credentials)" Продавца или какую-то другую гарантию на товары или услуги. |
Блок выбора TPO содержит результаты выбора, сделанного из списка, содержащегося в блоке протокольных опций (смотри раздел 8.1). Определение блока выбора TPO предлагается ниже.
<!ELEMENT TpoSelectionBlk (BrandSelection+) >
<!ATTLIST TpoSelectionBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок выбора TPO транзакции IOTP. |
| BrandSelection | Идентифицирует выбор вида платежаи платежного протокола, которы следует использовать при оплате в транзакции IOTP. Имеется один компонент выбора вида платежа (смотри раздел 7.8) для каждого предстоящего платежа транзакции IOTP. |
8.3. Блок отклика Offer
Блок отклика Offer содержит подробности о товарах, услугах, сумме, инструкций доставки или финансовых операциях, которые должны быть осуществлоены. Его определение дано ниже.
<!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*)>
<!ATTLIST OfferRespBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок отклика Offer транзакции. |
| Status | Содержит статусную информацию об успехе или неудаче подготовки предложения (смотри раздел 4.2). Заметим, что в блоке отклика Offer, значения ProcessState NotYetStarted или InProgress являются нелегальными. |
| Order | Компонент Order содержит подробности о товарах, услугах или финансовой операции, которая имеет место, смотри раздел 7.5. |
Компонент Order должен присутствовать, если только атрибут ProcessState компонента Status не равен Failed.
| Payment | Компоненты Payment содержат информацию о платежах, которые надлежит произвести, смотри раздел 7.9. |
| Delivery | Компонент Delivery содержит детали предстоящей доставки (смотри раздел 7.13). |
| TradingRoleData | Компонент информации о торговой роли содержит данными должны обменяться торговые роли, вовлеченные в транзакцию (смотри раздел 7.17). |
компонент Order транзакции; компоненты Payment для каждой проплаты транзакции; компонент Delivery транзакции (если предусмотрено). 8.4. Блок запроса аутентификации
Блок запроса аутентификации содержит данные, которые используются одной из торговых ролей для получения информации и опционно для аутентификации другой торговой роли. Этот блок содержит:
информацию о том, как аутентифицировать себя и/или запрос о дополнительной информации об организации, которую надлежит аутентифицировать. Его определение предагается ниже.
<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?)>
<!ATTLIST AuthReqBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок запроса аутентификации транзакции. |
| AuthReq | Каждый компонент запроса аутентификации (смотри раздел 7.2) описывет альтернативный путь, с помощью которого получатель запроса аутентификации может себя аутентифицировать, генерируя компонент отклика аутентификации (смотри раздел 7.3). |
Если нет ни одного компонента запроса аутентификации, это означает, что блок аутентификационного запроса запрашивает присылку компонентов Organisation, как это специфицировано в компоненте информационного запроса торговой роли.
| TradingRoleInfoReq | Компонент информационного запроса торговой роли (смотри раздел 7.4) содержит список торговых ролей, данные о которых запрашиваются. |
8.5. Блок отклика аутентификации
Блок отклика аутентификации содержит отклик, который является результатом обработки блока запроса аутентификации. Его определение представлено ниже.
<!ELEMENT AuthRespBlk (AuthResp?, Org*) >
<!ATTLIST AuthRespBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок отклика аутентификации транзакции. |
| AuthResp | Опционный компонент аутентификационного отклика, который содержит результаты обработки компонента запроса аутентификации – смотри раздел 7.3. |
| Org | Опционные компоненты Organisation, которые содержат информацию, соответствующую торговым ролям, как это запрошено атрибутом TradingRoleList компонента информационного запроса торговой роли. |
8.6. Блок состояния аутентификации
Блок состояния аутентификации индицирует успех или неудачу верификации блока отклика аутентификации аутентификатором. Его определение представлено ниже.
<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок состояния аутентификации транзакции. |
| Status | Содержит статусную информацию об успехе или неудаче аутентификации (смотри раздел 4.2). |
Блок платежного запроса содержит информацию, которая запускает процедуру платежа. Его описание представлено ниже.
<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*, TradingRoleData*)>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок платежного запроса транзакции. |
| Status | Содержит компоненты Status (смотри раздел 7.13) откликов на шаги (напр., отклика Offer и/или Payment), от которых данный шаг зависит. Он используется чтобы индицировать успех или неудачу этих шагов. Платеж может состояться лишь тогда, когда все предыдущие шаги были успешными. |
| BrandList | Компонент списка видов платежа содержит список из одного или более видов платежа и протоколов, которые могут быть выбраны (смотри раздел 7.7). |
| BrandSelection | Идентифицирует выбор вида платежа, платежного протокола и Кассира, которые должны быть использованы при оплате в данной транзакции. Имеется один компонент выбора вида платежа (смотри раздел 7.8) для каждой проплаты, которую следует выполнить в процессе транзакции. |
| Payment | Компоненты Payment содержит информацию о платеже, который выполняется, смотри раздел 7.9. |
| PaySchemeData | Компонент Payment Scheme содержит специфические данные о платежной схеме, смотри раздел 7.10. |
| Org | Компонент Organisation содержит подробности об организациях, вовлеченных в платеж (смотри раздел 7.6). Присутствие организаций зависит от транзакции и данных, которые должны быть подписаны. Смотри раздел 6. |
| TradingRoleData | Компонент данных о торговой роли содержит информацию, которая нужна для пересылки между торговыми ролями, вовлеченными в транзакцию (смотри раздел 7.17). |
Компонент Organisation с торговой ролью продавца; Компонент Organisation с торговой ролью Покупателя; Компонент Payment для платежа; Компонент Brand List; Компонент выбора вида платежа из списка; Компонент Organisation для Кассира, осуществляющего платеж; Компонент Organisation (если такоая имеется) для организации, которая выполнила предыдущий шаг, например другой Кассир; Компонент Organisation для организации, которая выполняет следующий шаг. Это может быть, например, Агент доставки или Кассир; Компонент Organisation для любых дополнительных организаций, которые Продавец включил в блок отклика Offer; Опционный компонент данных платежной схемы, если это требуется методом платежа, определенном в приложении IOTP; Любой компонент информации о платежной роли, который может потребоваться (смотри раздел 7.17.1). 8.8.
Блок платежного обмена
Блок платежного обмена содержит специфические данные о платежной схеме, которыми обмениваются две торговые роли в рамках сделки. Его определение представлено ниже.
<!ELEMENT PayExchBlk (PaySchemeData+)>
<!ATTLIST PayExchBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок платежного обмена транзакции. |
| PaySchemeData | Этот торговый компонент содержит специфические данные о платежной схеме, смотри раздел 7.10. |
Этот блок платежного отклика содержит информацию о состоянии платежа, опционной платежной расписке и опционные сообщения платежного протокола. Его определение представлено ниже.
<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
PaymentNote?, TradingRoleData*)>
<!ATTLIST PayRespBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок платежного отклика транзакции. |
| Status | Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) платежа. Заметим, что в блоке платежного отклика, значения ProcessState NotYetStarted или InProgress являются нелегальными. |
| PayReceipt | Содержит специфические данные о платежной схеме, которые могут быть использованы для верификации произведенного платежа. Смотри раздел 7.11. Он должен присутствовать, если атрибут ProcessState компонента Status равен CompletedOk. Атрибут PayReceipt является опционным. |
| PaySchemeData | Содержит специфические данные о платежной схеме, например, о сообщениях платежного протокола. Смотри также раздел 7.10. |
| PaymentNote | Содержит дополнительную, несвязанную с платежом информацию, которую кассир желает предоставить покупателю. Например, если выполнен отзыв сделки или осуществлен депозит, он может содержать данные о полученном балансе на счету, после того как данная операция завершена. Смотри раздел 7.12. |
| TradingRoleData | Компонент информации о торговой роли содержит данные, которые нужны для обмена между ролями, участвующими в транзакции (смотри раздел 7.17). |
Блок запроса доставки
Блок запроса доставки содержит подробности о товарах или услугах, которые должны быть предоставлены вместе с подписью, которая позволяет удостовериться, что доставка была авторизована. Его определение приведено ниже.
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
ConsumerDeliveryData?, TradingRoleData*)>
<!ATTLIST DeliveryReqBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок запроса доставки транзакции. |
| Status | Содержит компоненты Status (смотри раздел 7.13) откликов на шаги (напр., платежный отклик), от которых данный шаг зависит. Он используется чтобы индицировать успех или неудачу этих шагов. Доставку следует осуществлять только если все прдыдущие шаги завершились успешно. |
| Order | Компонент Order содержит подробности о товарах, услугах или финансовых операциях, которые имеют место, смотри раздел 7.5. Комоненты Organisation (смотри раздел 7.6) идентифицируют организации их роли. |
| Org | Транзакция IOTP. Роли и организации, которые должны присутствовать зависят от конкретного типа транзакции. Описания транзакций смотри в разделе 9. |
| Delivery | Компонент Delivery содержит подробности доставки, которую следует осуществить (смотри раздел 7.13). |
| ConsumerDeliveryData | Опционный. Содержит идентификатор, специфицированный Покупателем, который в случае возвращения Агентом доставки позволяет покупателю определить, о какой доставке идет речь. |
| TradingRoleData | Компонент данных о торговой роли содержит информацию, которая нужна при обмене между двумя торговыми ролями в процессе транзакции (смотри раздел 7.17). |
Компонент Organisation с торговой ролью Продавца; Компонент Organisation для торговых ролей Покупателя и DeliverTo; Компонент Delivery; Компонент Organisation для Агента доставки. В частности компонент Organisation, идентифицированный атрибутом ActionOrgRef компонента Delivery; Компонент Organisation (если имеется) для организации, которая осуществила предыдущий шаг, например Кассира; Компоненты Organisation для любой дополнительной организации, которую Продавец включил в блок отклика Offer; Любые компоненты данных о торговой роли, которая может потребоваться (смотри раздел 7.17.1). 8.11.
Блок отклика доставки
Блок отклика доставки содержит Delivery Note, содержащую подробности о том как будут доставляться товары. Его определение представлено ниже. Заметим, что в блоке отклика Delivery элемент состояния доставки с DeliveryStatusCode равным NotYetStarted или InProgress является нелегальным.
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote)>
<!ATTLIST DeliveryRespBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок отклика доставки транзакции. |
| Status | Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) доставки. Заметим, что в блоке отклика Delivery, ProcessState равный NotYetStarted или InProgress считается нелегальным. |
| DeliveryNote | Компонент Delivery Note содержит подробности о том, как будут доставляться товары или услуги (смотри раздел 7.15). |
Торговый блок информационного запроса содержит компоненттип запроса и опционно платежной схемы.
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет торговый блок информационного запроса транзакции. |
| InquiryType | Компонент тип информационного запроса (смотри раздел 7.18), который содержит код типа запроса. |
| PaySchemeData | Компонент платежная схема (Payment Scheme) (смотри раздел 7.10), который содержит специфические данные конкретных информационных запросов о платежной схеме. Он присутствует, когда атрибут Type компонента типа запроса равен Payment. |
Торговый блок информационного отклика содержит компонент Status и опционно компонент Payment Scheme. Его целью является осуществление запроса о текущем состоянии транзакции или сервера.
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?)>
<!ATTLIST InquiryRespBlk ID ID #REQUIRED
LastReceivedIotpMsgRef NMTOKEN #IMPLIED
LastSentIotpMsgRef NMTOKEN #IMPLIED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет торговый блок информационного отклика транзакции. |
| LastReceivedIotpMsgRef | Содержит ссылку элемента (смотри раздел 3.5) на Id-компонент (смотри раздел 3.3.2) последнего сообщения, которое получил данный сервер от покупателя. Если до этого не получено от покупателя ни одного сообщения, этот атрибут должен содержать значение (Null). Данный атрибут предназначен для отладочных целей. |
| LastSentIotpMsgRef | Содержит ссылку элемента (смотри раздел 3.5) на Id-компонент (смотри раздел 3.3.2) последнего сообщения, которое послал данный сервер покупателю. Если до этого не послано ни одного сообщения покупателю, данный атрибут должен содержать значение (Null). Этот атрибут предназначен для отладочных целей. |
| Status | Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) определенного торгового обмена (т.e., предложения, платежа или доставки). |
| PaySchemeData | Компонент Payment Scheme (смотри раздел 7.10), который содержит специфические информационные запросы по поводу платежной схемы. Он присутствует, когда атрибут Type атрибута StatusType компонента Status равен Payment. |
Блок запроса Ping используется, чтобы определить, работает ли сервер и является ли криптография совместимой.
Определение блока запроса Ping предложено ниже.
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет запрос Ping торгового блока транзакции. |
OrgОпционные компоненты Organisation (смотри раздел 7.6).
Если нет ни одного компонента Organisation, тогда запрос Ping является анонимным и служит для проверки, работает ли сейчас сервер.
Однако, если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping хочет проверить, могут ли быть обработаны цифровые подписи.
В этом случае отправитель включает:
Компонент Organisation, который идентифицирует сам себя, специфицируя торговую роль (или роли), которую он исполняет в транзакции (Продавец, Кассир, и т.д.) Компонент Organisation, который идентифицирует получателя сообщения. Эти компоненты используются для формирования подписи блока отклика Ping.
8.15. Блок отклика Ping
Блок отклика Ping предоставляет результат выполнения запроса Ping. Он содержит компонент Organisation, который идентифицирует отправителя отклика Ping.
Если запрос Ping, для которого этот блок является откликом, содержал компоненты Organisation, тогда он также содержит эти компоненты Organisation.
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk ID ID #REQUIRED
PingStatusCode (Ok | Busy | Down) #REQUIRED
SigVerifyStatusCode (Ok | NotSupported | Fail) #IMPLIED
xml:lang NMTOKEN #IMPLIEDPingStatusDesc CDATA #IMPLIED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет торговый блок запроса Ping транзакции. |
| PingStatusCode | Содержит код, который показывает состояние программы отправителя, которая обрабатывает IOTP-сообщения. Допустимыми значениями являются: o Ok. Сервис работает нормально, включая проверку подписей. o Busy. Все идет хорошо, но возможны некоторые задержки. o Down. Сервер не вполне функционален, но все же может выдать отклик Ping. |
| SigVerifyStatusCode | Заключает в себе код, который показывает состояние проверки подписи. Он присутствует только когда сообщение, содержащее блок запроса Ping имеет также блок Signature. Допустимы следующие значения: o Ok. Веоификация подписи прощла успешно. o NotSupported. Получатель блока запроса Ping не поддерживает валидацию подписей. o Fail. Верификация подписи не прошла. |
| Xml:lang | Определяет язык, использованный в PingStatusDesc. Присутствует тогда, когда имеется PingStatusDesc. |
| PingStatusDesc | Содержит короткое описание состояния сервера, который поылает этот блок отклика Ping. Сервер, если его разработчики хотят, может использовать этот атрибут для посылки более детальной информации, чем содержится в PingStatusCode, он может использоваться, например, для отладрчных целей. |
| Org | Компоненты Organisation (смотри раздел 7.6). |
Значения статусного кода Ping не включают в себя такие значения как Fail, так как, когда программа, получающая сообщение запроса Ping, не работает, не будет послано никакого отклика Ping.
8.16. Блок подписи
Блок Signature содержит один или более компонентов Signature и соответствующих сертификатов (если требуется), которые подтверждают данные в рамках данной транзакции. Определение компонента Signature и сертификатов содержится в статье "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Описание их применения в IOTP можно найти в разделах 7.19 и 7.20.
Определение блока Signature представлено ниже:
<!ELEMENT IotpSignatures (Signature+, Certificate*) >
<!ATTLIST IotpSignatures ID ID #IMPLIED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок подписи транзакции. |
| Signature | Компонент Signature. Смотри раздел 7.19. |
| Certificate | Компонент Certificate. Смотри раздел 7.20. |
8.16.1. Блок подписи в отклике предложении
Блок подписи, который содержится в том же сообщении, что и блок отклика Offer, несет в себе только компонент подписи отклика Offer (смотри раздел 7.19.2).
8.16.2. Блок подписи в платежном запросе
Блок Signature, который содержится в том же сообщении, что и блок платежного запроса, содержит в себе:
Компонент подписи отклика Offer (смотри раздел 7.19.2) и Если поатеж зависит от предыдущего шага (как указано атрибутом StartAfter компонента Payment), тогда компонент подписи платежной расписки (смотри раздел 7.19.3) генерируется на предыдущем этапе (шаге). 8.16.3. Блок подписи в платежном отклике
Блок подписи, который содержится в том же сообщении, что и блок платежного отклика, содержит только компонент подписи платежной расписки (смотри раздел 7.19.3), сформированной на этом этапе (шаге).
8.16.4. Блок подписи в запросе доставки
Блок подписи, который содержится в том же сообщении, что и блок запроса доставки, содержит:
Компонент подписи отклика Offer (смотри раздел 7.19.2) и Компонент подписи платежной расписки (смотри раздел 7.19.3), сформированный на предшествующем шаге. 8.16.5. Блок подписи в отклике доставки
Блок Signature, который содержится в том же сообщении, что и блок отклика доставки, содержит только компонент подписи отклика Delivery (смотри раздел 7.19.4), сформированный на этом шаге.
8.17. Блок ошибки
Торговый блок Error содержит один или более компонентов Error (смотри раздел 7.21), которые несет в себе информацию о технических ошибках (смотри раздел 4.1) в сообщении IOTP, полученном одной из торговых ролей, вовлеченных в сделку.
Ниже представлены две фразы, которые используются в описании торгового блока Error:
ошибочное сообщение. Сообщение IOTP, которое содержит или является причиной ошибки какого-то рода; сообщение, опровещающее об ошибке. Сообщение IOTP, которое содержит торговый блок Error, описывающий ошибку, найденную в сообщении. Торговый блок Error может содержаться в любом сообщении, уведомляющем об ошибке. Реакция на такое сообщение зависит от серьезности (severity) ошибки. Разъяснения различных значений серьезности ошибки (и сопряженных с ними действий) дано в определении компонента Error.
Несмотря на то что торговый блок Error может уведомлять о многих различных ошибках, используя несколько компонентов Error, разработчики приложений могут и не поддерживать такую возможность.
Структура торгового блока Error представлена ниже.
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок Error транзакции. |
| ErrorComp | Компонент Error (смотри раздел 7.21), который содержит информацию об индивидуальной технической ошибке. |
| PaySchemeData | Опционный компонент Payment Scheme (смотри раздел 7.10), который содержит описание платежной схемы. |
Блок Cancel используется одной торговой ролью чтобы информировать остальных о том, что транзакция аннулируется.
Пример использования включает в себя:
Роль Покупателя, информирующую других о том, что он не собирается продолжать транзакцию. Это позволяет серверу завершить транзакцию, не дожидаясь таймаута. Роль, отличная от покупателя, информирует Покупателя о том, что транзакция останавливается. В этом случае Покупатель вряд ли повторно пошлет предыдущее сообщение в предположении, что оно не было получено. Его определение имеет вид.
<!ELEMENT CancelBlk (Status) >
<!ATTLIST CancelBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок Cancel транзакции. |
| Status | Содержит статусную информацию, указывающую, что транзакция была аннулирована. |
Торговые компоненты
7. Торговые компоненты
Далее рассматриваются торговые компоненты, используемые в IOTP. Торговые компоненты являются дочерними XML-элементами, что показано на диаграмме Рисунок .14.
Содержимое атрибута зависит от транспортного механизма.
| SecureSenderNetLocn | Содержит безопасный сетевой узел отправителя блока TPO, в котором содержится компонент протокольных опций. |
| SuccessNetLocn | Содержит сетевую позицию, которая должна быть отображена после успешного завершения транзакции. |
7.2. Компонент запроса аутентификации
Этот торговый компонент содержит параметр данных, которые используются при аутентификации одной торговой роли у другой. Его определение представлено ниже.
<!ELEMENT AuthReq (Algorithm, PackagedContent*)>
<!ATTLIST AuthReq ID ID #REQUIRED
AuthenticationId CDATA #REQUIREDContentSoftwareId CDATA #IMPLIED>
Если требуется, алгоритм может использовать данные вызова, содержащиеся в элементах Packaged Content из компонента запроса аутентификации. Формат Packaged Content является зависимым от алгоритма.
Атрибуты:
| ID | Идентификатор, который однозначно идентифицирует компонент запроса аутентификации для данной транзакции IOTP. |
| AuthenticationId | Идентификатор, специфицированный аутентификатором, который, если прислан организацией, которая получает запрос, позволит аутентификатору определить, какая аутентификационная процедура требуется. |
| ContentSoftwareId | Смотри раздел 14. Словарь |
| PackagedContent | Содержит данные вызова в виде одного или более элементах Packaged Content (смотри раздел 3.7), на которые следует рееагировать, используя алгоритм, опреденный элементом Algorithm. |
| Algorithm | Содержит информацию, которая описывает алгоритм (смотри 7.19. Компоненты подписи), который должен быть использован для генерации отклика аутентификации. |
7.3. Компонент отклика аутентификации
Компонент отклика аутентификации содержит результаты аутентификационного запроса.
Используется алгоритм, содержащийся в компоненте запроса аутентификации (смотри раздел 7.2) и выборанный из блока запроса аутентификации (смотри раздел 8.4).
В зависимости от выбранного алгоритма, результаты его применения будут содержаться в компоненте подписи, которая подтверждает отклик аутентификации, или в элементах Packaged Content компонента отклика аутентификации. Его определение представлено ниже.
<!ELEMENT AuthResp (PackagedContent*) >
<!ATTLIST AuthResp ID ID #REQUIRED
AuthenticationId CDATA #REQUIREDSelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Атрибуты:
| ID | Идентификатор, который для данной транзакции однозначно определяет компонент отклика аутентификации. |
| AuthenticationId | Идентификатор аутентификации, специфицированный аутентификатором, который был включен компонент запроса (смотри раздел 7.2). Это позволяет аутентификатору идентифицировать метод аутентификации. |
| SelectedAlgorithmRef | Ссылка элемента, которая определяет элемент алгоритма, сипользуемого для формирования отклика аутентификации. |
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Может содержать отклик, сформированный в качестве результата применения алгоритма, выбранного из компонента запроса аутентификации, смотри раздел 7.2. |
7.4. Компонент запроса информации торговой роли
Этот торговый компонент содержит список торговых ролей (смотри раздел 2.1), информация для которых запрошена. Результатом запроса торговой роли является набор компонентов Organisation (смотри раздел 7.6), которые описывают каждую из запрошенных торговых ролей. Его определение приведено ниже.
<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq ID ID #REQUIRED
TradingRoleList NMTOKENS #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент информационного запроса для торговой роли в рамках транзакции IOTP. |
| TradingRoleList | Содержит список из одной или более торговых ролей (смотри атрибут TradingRole элемента Trading Role – раздел 7.6.2), для которых была запрошена информация. |
Компонент заказа
Компонент Order содержит информацию о заказе. Его определение представлено ниже.
<!ELEMENT Order (PackagedContent*) >
<!ATTLIST Order ID ID #REQUIRED
| xml:lang NMTOKEN #REQUIRED | OrderIdentifier CDATA #REQUIRED |
| ShortDesc CDATA #REQUIRED | OkFrom CDATA #REQUIRED |
| OkTo CDATA #REQUIRED | ApplicableLaw CDATA #REQUIRED |
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент Order в пределах текущей транзакции IOTP. |
| xml:lang | Определяет язык, использованный атрибутами или дочерними элементами в пределах компонента, если только его значение не было изменено с помощью атрибута xml:lang дочернего элемента. Смотри раздел 3.8. |
| OrderIdentifier | Это код, число или другой идентификатор, который автор заказа может использовать для идентификации заказа. В пределах транзакции он должен быть уникальным. Если он используется так, то нет нужды специфицировать содержимое элемента заказа, так как имеется ссылка на нужную информацию в базе данных. |
| ShortDesc | Краткое описание заказа на языке, определенном атрибутом xml:lang. Оно используется для упрощения выбора индивидуального заказа из списка, например, из базы данных заказов, записанных туда продавцом, покупателем и т.д.. |
| OkFrom | Дата и время в формате [UTC], после которого предложение, сделанное Продавцом теряет силу. |
| OkTo | Дата и время в формате [UTC], до которого получатель может воспринимать предложение продавца не имеющим силу. |
| ApplicableLaw | Фраза на языке, определенном атрибутом xml:lang, которая описывает штат или страну, юристдикция которой будет использована при разрешении конфликтов и споров. |
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Опционное описание заказа в виде одного или более элементов Packaged Content (смотри раздел 3.7). |
Элемент Packaged Content будет в норме необходим, однако он может быть опущен там, где достаточная информация о покупке может быть получена из атрибута ShortDesc.
Если необходимо полное описание заказа, могут использоваться несколько элементов Packaged Content.
Хотя сумма и валюта вероятно присутствуют в элементах Packaged Content описания заказа, они содержатся в торговых компонентах, связанных с платежом (список видов платежа, выбор вида платежа и платеж). Это означает, что важно, чтобы сумма, которая действительно дожна быть уплачена, была четко отображена для Покупателя.
Для совместимости разные реализации должны поддерживать как минимум Plain Text, HTML и XML, что облегчит отображение.
7.5.2. Временные метки OkFrom и OkTo
Заметим, что:
Дата OkFrom может быть позже чем дата OkFrom компонента Payment (смотри раздел 7.9), связанного с этим заказом, и аналогично, дата OkTo может быть раньше чем дата OkTo компонента Payment (смотри раздел 7.9). Продавец в контексте Интернет-коммерции в исходный момент с анонимными покупателями выявляет условия предложения на WEB-странице. Для того чтобы получить товар или услуги покупатель должен согласиться с этими условиями.
Если предложение ограничено временными рамками, рекомендуется, чтобы продавцы взаимодействовали с покупателями и сообщали им условия заказа в понятной для них форме:
предложение ограничено по времени; временные метки OkFrom и OkTo специфицируют время действия предложения; часы, напр., часы продавца, будут использоваться для определения действия предложения. Заметим также, что даты OkFrom и OkTo могут также присутствовать в элементах Packaged Content описания заказа, эти даты содержатся в компоненте Order. Важно, чтобы даты OkFrom и OkTo использовались в формате, приемлемом для покупателя.
7.6. Компонент Organisation
Компонент Organisation предоставляет информацию об индивидууме или организации. Он может быть использован для различных целей, например:
описать продавца, который продает товары, идентифицировать того, кто осуществляет покупку, идентифицировать того, кто будет доставлять товары, обеспечивать облуживание покупателя, описать того, кто будет Кассиром. Заметим, что компоненты Organisation, которые должны присутствовать в сообщении IOTP, зависят от выполняемой транзакции.
Смотри раздел 9.
Ниже представлено определение компонента.
<!ELEMENT Org (TradingRole+, ContactInfo?, PersonName?, PostalAddress?)>
<!ATTLIST Org ID ID #REQUIRED
| xml:lang NMTOKEN #REQUIRED | OrgId CDATA #REQUIRED |
| LegalName CDATA #IMPLIED | ShortDesc CDATA #IMPLIED |
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент Organisation в пределах текущей транзакции IOTP. |
| xml:lang | Определяет язык, использованный атрибутами или дочерними элементами в пределах данного компонента, если только его значение не было изменено с помощью атрибута xml:lang дочернего элемента. Смотри раздел 3.8. |
| OrgId | Код, который идентифицирует организацию, описанную компонентом Organisation. Смотри 7.6.1. |
| LegalName | Для организаций, которые являются коммерческими компаниями, это их легальное название на языке, определенном атрибутом xml:lang. Это необходимо для организаций, чьими торговыми ролями не являются Покупатель или DelivTo. |
| ShortDesc | Краткое описание организации на языке, определенном атрибутом xml:lang. Это обычно имя, под которым известна организация. Например, если легальное название было "Blue Meadows Financial Services Inc.", тогда его короткое имя может быть "Blue Meadows". |
| LogoNetLocn | Сетевая позиция, которая может быть использована для загрузки логотипа организации. |
Cодержимое:
| TradingRole | Смотри 7.6.2. Элемент торговой роли. |
| ContactInfo | Смотри 7.6.3. Элемент контактной информации. |
| PersonName | Смотри 7.6.4. Персональное имя. |
| PostalAddress | Смотри 7.6.5. Почтовый адрес. |
ID организаций используются одной из торговых ролей для идентификации торговой роли. Для того чтобы избежать путаницы, это означает, что эти ID должны быть глобально уникальными.
На практике это достигается следующим образом:
Id организации для всех торговых ролей, за исключением торговой роли Покупателя, используют имена доменов, так как они уникальны по определению, Id организации для торговой роли покупателя выделяется одной из прочих торговых ролей в транзакции и делается уникальным путем присоединения его к другим Id организаций, если покупателю выделено Id организации для данной транзакции, это же Id используется всеми другими торговыми ролями в рамках этой транзакции для идентификации покупателя. В частности, содержимое ID организации определяется следующим образом:
OrgId ::= NonConsumerOrgId | ConsumerOrgId
NonConsumerOrgId ::= DomainName
ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" NonConsumerOrgId
ConsumerOrgIdPrefix ::= "Consumer:"
ConsumerOrgIdID организации покупателя состоит из:
стандартного префикса, чтобы идентифицировать то, что это организация покупатель. Далее следует один или более символов, которые согласуются с определением "namechar" XML. Смотри спецификации [XML]. За ними следует NonConsumerOrgId организации, которая выдала ConsumerOrgId. Обычно это продавец. Применение символов в верхнем или нижнем регистре не играет роли.
| NonConsumerOrgId | Если роль не соответствует покупателю, тогда здесь содержится каноническое имя этой организации. Смотри [DNS], за которым опционно следуют дополнительные символы, если требуется сделать NonConsumerOrgId уникальным. |
newjerseybooks.comid организации-продавца; westernbank.co.ukid организации-кассира; consumer:1000247ABH/newjerseybooks.comid организации-покупателя выданный продавцом. 7.6.2. Элемент торговая роль
Этот элемент идентифицирует торговую роль человека или организации в данной транзакции IOTP. Заметим, что организация может иметь более чем одну торговую роль и несколько ролей может присутствовать в одном элементе Organisation.
Определение элемента представлено ниже:
<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole ID ID #REQUIRED
| TradingRole NMTOKEN #REQUIRED | IotpMsgIdPrefix NMTOKEN #REQUIRED |
| CancelNetLocn CDATA #IMPLIED | ErrorNetLocn CDATA #IMPLIED |
Атрибуты:
| ID | Идентификатор, который однозначно определяет элемент торговая роль в пределах текущей транзакции IOTP. |
| TradingRole |
Торговая роль организации. Возможные значения: o Покупатель. Лицо или организация, которая действует в роли покупателя в данной транзакции. o Продавец. Лицо или организация, которая действует в роли продавца в данной транзакции. o Агент доставки. Лицо или организация, которая доставляет товар или предоставляет услуги в рамках данной транзакции; o DelivTo. Лицо или организация, которая получает товары или услуги в рамках данной транзакции. o CustCare. Лицо или организация, которая обеспечивает обслуживание покупателя в данной транзакции. |
| IotpMsgIdPrefix | Содержит префикс, который должен быть использован для всех IOTP сообщений, посланных торговой ролью в данной транзакции. Значения, которые следует использовать определены в 3.4.1. |
| CancelNetLocn | Содержит сетевую позицию, куда покупатель должен обратиться, если он аннулирует транзакцию по какой-либо причине. Атрибут может быть использован торговой ролью для отправки отклика, который более соответствует обстоятельствам конкретной транзакции. |
не должен присутствовать, когда TradingRole усановлено равным роли Покупателя или DelivTo, должен присутствовать, когда TradingRole = Продавец, Кассир или Агент доставки. Содержимое этого атрибута зависит от транспортного механизма.
| ErrorNetLocn | Содержит сетевую позицию, которая должна отображаться Покупателем, после того как он получил или сгенерировал блок Error, содержащий компонент Error с атрибутом Severity равным: |
не должен присутствовать, когда TradingRole равно Покупатель или DelivTo, должен присутствовать, когда TradingRole равно Продавец, Кассир или Агент доставки. Содержимое атрибута зависит от транспортного механизма.
| ErrorLogNetLocn | Опционно. Содержит сетевую позицию, куда Покупателю следует посылать IOTP сообщения, которые содержат блоки Error с компонентами Error сатрибутом Severity равным: |
не должен присутствовать, когда TradingRole = Покупатель, должен присутствовать, когда TradingRole равно Продавец, Кассир или Агент доставки. Содержимое этого атрибута зависит от транспортного механизма.
Атрибут ErrorLogNetLocn может использоваться для посылки сообщений об ошибках программной компании или другой оргаанизации, ответственной за решение проблем с программами, которые посылают входные сообщения. Смотри раздел 7.21.1.
7.6.3. Элемент контактной информации
Этот элемент содержит информацию, которая может быть использована для контакта с организацией или частным лицом. Все атрибуты являются опционными, однако по крайней мере один из элементов контактной информации должен присутствовать. Его определения представлено ниже.
<!ELEMENT ContactInfo EMPTY >
| <!ATTLIST ContactInfo xml:lang | NMTOKEN #IMPLIED |
| Tel CDATA #IMPLIED | Fax CDATA #IMPLIED |
| Email CDATA #IMPLIED | NetLocn CDATA #IMPLIED > |
| xml:lang | Определяет язык данного элемента. Смотри раздел 3.8. |
| Tel | Телефонный номер, по которому можно контактировать с организацией. Заметим, что это текстовое поле и проверок корректности содержимого не производится. |
| Fax | Номер факса, по которому можно контактировать с организацией. Заметим, что это текстовое поле и проверок корректности содержимого не производится. |
| Адрес электронной почты, по которому можно контактировать с организацией. Заметим, что поле должно следовать регламентациям для адресных спецификаций, содержащимся в [RFC822]. | |
| NetLocn | Адрес Интернет, по которому можно найти информацию об организации, используя WEB-броузер. |
7.6.4. Элемент личного имени
Этот элемент содержит имя частного лица. Все поля являются опционными, однако GivenName (имя) или FamilyName (фамилия) должны присутствоать. Его опредление представлено ниже.
<!ELEMENT PersonName EMPTY >
| <!ATTLIST PersonName xml:lang | NMTOKEN #IMPLIED |
| Title CDATA #IMPLIED | GivenName CDATA #IMPLIED |
| Initials CDATA #IMPLIED | FamilyName CDATA #IMPLIED > |
| xml:lang | Определяет язык с помощью атрибута внутри элемента. Смотри раздел 3.8. |
| Title | Отличительное имя; личное прозвище, наследственное или нет, должность (напр., судья, мэр), дворянское звание (напр., герцог, герцогиня, граф), или используемое при обращение к человеку (напр., Mr, Mrs, Miss, товарищ, господин) |
| GivenName | Имя, под которым человек известен в семье, друзьям или знакомым (имя или фамилия). |
| Initials | Первая буква второго имени (отчества), под которым человек известен в своей семье, друзьям или знакомым. |
| FamilyName | Фамилия. Это обычно часть персонального имени, которая передается по наследству от родителей к детям. |
Этот элемент содержит адрес, который может быть использован, например, для физической доставки товаров, услуг или писем. Его определение предлагается ниже.
<!ELEMENT PostalAddress EMPTY >
| <!ATTLIST PostalAddress xml:lang | NMTOKEN #IMPLIED |
| AddressLine1 CDATA #IMPLIED | AddressLine2 CDATA #IMPLIED |
| CityOrTown CDATA #IMPLIED | StateOrRegion CDATA #IMPLIED |
| PostalCode CDATA #IMPLIED | Country CDATA #IMPLIED |
Атрибуты:
| xml:lang | Определяет язык, используемый атрибутами в этом элементе. Смотри раздел 3.8. |
| AddressLine1 | Первая строка почтового адреса, напр.,"The Meadows" |
| AddressLine2 | Вторая строка почтового адреса. напр.,"Sandy Lane" |
| CityOrTown | Город в адресе, напр.,"Москва" |
| StateOrRegion | Штат или область в пределах страны, где находится город, напр., "Зюзино" |
| PostalCode | Код, известный как, например почтовый код или zip-код, который обычно используется почтовыми организациями для организации эффективной доставки, напр.,"113303" |
| Country | Страна адреса, напр.,"RU" |
| LegalLocation | Идентифицирует, является ли адрес зарегистрированным адресом организации. По крайней мере один адрес организации должен соответствовать значению “истина” в противном случае торговой ролью является Покупатель или DeliverTo. |
7.7. Компонент списка видов платежей
Компоненты списка видов платежа содержатся в блоке опций торгового протокола (смотри раздел 8.1) транзакции IOTP. Они содержат список:
виды платежа (смотри также раздел 11.1), суммы, которые должны быть заплачены в валюте, которую выбрал или предложил Продавец, платежные протоколы, которые могут использоваться для реализации заданного вида платежа, сетевые позиции Кассиров, которые воспринимают платеж в рамках платежного протокола. Определение компонента списка видов платежа представлено ниже.
<!ELEMENT BrandList (Brand+, ProtocolAmount+, CurrencyAmount+, PayProtocol+)>
<!ATTLIST BrandList ID ID #REQUIRED
xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED
PayDirection (Debit | Credit) #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент списка видов платежа транзакции IOTP. |
| xml:lang | Определяет язык, использованный атрибутами или дочерними элементами в пределах данного компонента, если только его значение не переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8. |
| ShortDesc | Текстовое описание на языке, заданном атрибутом xml:Lang, характеризующее цели списка видов платежа. Эта информация должна быть отображена у получателя списка видов платежа для того чтобы помочь сделать правильный выбор. Это привлекательно, так как позволяет Покупателю выяснить цели предлагаемого списка видов платежа, если транзакция предполагает несколько платежей. |
| PayDirection | Индицирует направление платежа для выбранного вида. Возможные значения: |
| Brand | Описывает вид платежа (Brand). Последовательность элементов Brand (смотри раздел 7.7.1) в списке видов плптежа не определяет каких-либо преоритетов. Рекомендуется, чтобы программа, которая обрабатывает этот список видов платежа представляла их в порядке предпочтения получателя. |
| ProtocolAmount | Это связывает конкретный вид платежа с: |
| CurrencyAmount | Содержит код валюты и сумму платежа; |
| PayProtocol | Содержит информацию о платежном протоколе и Кассире, которые могут использовать данный вид платежа. |
Торговые роли в IOTP
Рисунок .1. Торговые роли в IOTP
Определены следующие роли: Покупатель. Человек (или организация), который получает товар или услугу и платит за это. Продавец. Человек (или организация), у которого приобретается а, выполненного потребителем. товар или услуга, который оффициально ответственнен за их предоставление и кто извлекает выгоду в результате платеж. Оператор платежей. Субъект, который получает платеж от потребителя в пользу торговой фирмы или физического лица. Оператор доставки. Субъект, который доставляет товар или предоставляет услугу потребителю от торговой фирмы или лица. Лицо или фирма обслуживающая клиента торговой фирмы. Субъект, который вовлечен в обслуживание клиента торговой фирмы.
Роли могут выполняться одной организацией или различными организациями. Например:
В простейшем случае одна организация (напр., продавец) может оформлять покупку, принимать платеж, доставлять товар и осуществлять обслуживание покупателя. В крайнем случае, продавец может оформить покупку, но предложить покупателю осуществить платеж в банке, попросить доставить товар специальную фирму, выполняющую доставк, и обратиться к третей фирме, обеспечивающей круглосуточное обслуживание, с просьбой помочь покупателю в случае возникновения каких-то непредвиденных проблем.Заметим, что в этой спецификации, если не указано обратного, когда используются слова Покупатель (Consumer), Продавец (Merchant), Кассир (Payment Handler), Агент доставки (Delivery Handler) или обслуживание потребителя (Customer Care Provider), подрузамевается торговая роль (Trading Role), а не конкретная организация.
Любая конкретная организация может выполнять множество ролей. Например компания, которая продает товары или услуги через Интернет, может выполнять роь продавца при продаже товара или услуги и роль потребителя, когда компания покупает товары или услуги сама.
2.2. Торговый обмен
Протокол Интернет для торговли (The Internet Open Trading Protocols) идентифицируют четыре торговых обмена, которые включают обмен данными между торговыми ролями.
Среди них:
Предложение. Обмен предложения ( Offer Exchange) предполагает, что продавец предоставляет покупателю причины, почему сделка должна иметь место. Такой обмен называется предложением, если сделка может состояться.
Оплата. Платежный обмен (Payment Exchange) предполагает осуществление какого-то платежа между потребителем и кассиром. Направление платежа может быть любым.
Доставка. Процедура доставки (Delivery Exchange) сопряжена с передачей товаров или доставкой информации о товарах агентом доставки Потребителю.
Аутентификация. Аутентификационный обмен (Authentication Exchange) может использоваться любой из тоговых ролей для аутентификации другой торговой роли и выяснения является ли субъект тем, за кого он себя выдает.
Операции IOTP состоят из различных комбинаций этих торговых обменов. Например, операция покупки IOTP включает в себя обмены Предложения, Оплаты и Доставки. А операция обмена ценностями IOTP состоит из предложения и двух обменов оплаты.
Торговые обмены (Trading Exchanges) состоят из торговых компонентов, которые передаются между различными торговыми ролями. Где возможно, число круговых задержек в операциях IOTP минимизируется путем объединения компонентов нескольких торговых обменов в комбинированные сообщения IOTP. Например, операция покупки IOTP объединяет компонент организации доставки и компонент предложения, для того чтобы избежать лишних запросов и откликов Потребителя.
Ниже каждый торговый обмен IOTP описан более детально. Для простоты описания они рассматриваются как независимые процедуры.
2.2.1. Предложение
Целью обмена Предложения является обеспечение Покупателя информацией о сделке с тем чтобы он мог решить, продолжать ли ему эту сделку. Это продемонстрировано ниже на Рисунок .2.
| 1. | Покупатель (С) решает сделать покупку и шлет информацию о заказе продавцу (М), например в формате HTML. |
| C a M | Данные: информация о том, что покупается (запрос Предложения) – формат запроса не определен в рамках IOTP |
| 2. | Продавец проверяет информацию, выданную Покупателем, формирует предложение, опционно его подписывает и посылает Покупателю. |
| C ? M | Отклик на Предложение. Компоненты: Статус; Организации (покупатель, DelivTo, продавец, кассир, Агент обслуживания покупателя); Заказ; Платеж; Доставка; TradingRoleData подпись отклика-предложения (опционно) |
| 3. | Покупатель проверяет информацию от продавца и решает, стоит ли осуществлять покупку. |
Традиционные модемы могут обеспечить
Рисунок 1.5a). Традиционные модемы могут обеспечить при хорошем качестве коммутируемой аналоговой телефонной сети пропускную способность до 56 Кбит/с (кабельные широкополосные модемы при длине соединения порядка 2км могут обеспечить 2 Мбит/с). Привлекательность такого решения заключается в возможности подключения к любому узлу, имеющему модемный вход. Наиболее широко указанный метод связи используется для подключения к узлам Интернет домашних ЭВМ. Недостатком такого решения является низкая надежность канала (особенно в России), малая пропускная способность и необходимость большого числа входных телефонных каналов и модемов.
Использование выделенной 2- или 4-проводной линии (Рисунок 1.5Б) обеспечивает большую надежность и пропускную способность (до 256 кбит/с при длинах канала < 10 км). Но и здесь на каждый вход требуется отдельный модем, да и скоростные модемы, работающие на выделенную линию, относительно дороги. Выделенные линии чаще служат для межсетевого соединения (Рисунок 1.5В). Функциональным аналогом выделенных линий являются оптоволоконные, спутниковые и радио-релейные каналы. Этот вариант позволяет строить сети с пропускной способностью в несколько 1-100 Мбит/с и более.
Привлекательные возможности предлагают цифровые сети ISDN. Здесь можно использовать групповые телефонные номера, когда пара модемов обслуживает 10 и более пользователей (ведь они работают, как правило, не все одновременно). Кроме того, ISDN предлагает пользователям каналы с пропускной способностью не ниже 64кбит/c, а при необходимости возможно формирование и более широкополосных каналов. ISDN позволяет делить один и тот же канал между многими пользователями для передачи данных, факсов и телефонных переговоров. isdn органично стыкуется с внешними каналами X.25. К недостаткам системы следует отнести ограниченность ширины окна (число переданных пакетов без получения подтверждения приема), что делает неэффективным использование широкополосных и особенно спутниковых каналов. В области межсетевых связей свою нишу занимает Frame Relay. Этот протокол имеет контроль перегрузок, работающий на аппаратном уровне
Транзакции IOTP
9. Транзакции IOTP
Базовая версия протокола IOTP поддерживает три типа транзакций. Среди них:
Транзакции аутентификации IOTP, которые поддерживают аутентификацию одного партнера сделки другим партнером и/или получение информации о другой торговой роли. Транзакции IOTP, которые включают в себя один или более платежей. В частности:- Депозит
- Покупка
- Возврат денег
- Отзыв сделки
- Обмен ценностями
- Транзакция запроса состояния и
- Ping
Хотя транзакции аутентификации могут выполняться сами по себе, опционно любая платежная операция может предшествоваться аутентификацией. Остальная часть данного раздела поделена на две части, где описывается:
Аутентификационные и платежные транзакции (аутентификация, депозит, покупка, возврат денег, аннулирование сделки и обмен ценностями) Инфраструктурные транзакции (транзакция запроса состояния и Ping), которые предназначены для поддержки запросов о том, успешно ли прошла транзакция или правильно ли работает сервер торговой роли.9.1. Транзакции аутентификации и платежа
Транзакции, имеющие отношение к аутентификации и платежу состоят из шести документальных обменов, которые объединяются в последовательности, чтобы реализовать определенную транзакцию.
Вообще имеется теснаое но не точное соответствие между документальным и торговым обменами. Главное отличие заключается в том, что некоторые документальные обмены включают в себя часть или все два торговых обменов одновременно для того чтобы минимизировать число IOTP-сообщений, посылаемых через Интернет.
Эти шесть документальных обменов включают в себя:
Аутентификация. Это прямая реализация аутентификации торгового обмена; Предложение (Offer), зависимое от вида платежа. Это торговый обмен предложения, объединенный с платежным обменом выбора вида платежа. Его целью является обеспечение Продавца информацией о выборе вида платежа; Предложение, не зависимое от вида платежа. Это также торговый обмен предложения (Offer). Однако в этом случае содержимое отклика Offer не зависит от выбора вида платежа; Платеж. Это непосредственная реализация платежной части торгового обмена; Доставка. Это прямая реализация обмена доставки; Доставка с платежом. Это реализация совмещеных торговых обменов платежа и доставки.Эти документальные обмены скомбинированы вместе в различные последовательности, чтобы реализовать каждую из транзакций. Способ, которым они могут комбинироваться проиллюстрирован на Рисунок .17.
Требования к пропускной способности канала для различных видов сервиса
Рисунок 1.6. Требования к пропускной способности канала для различных видов сервиса.
Рассмотрев диаграмму, можно сделать определенные прогнозы на ближайшее будущее сетей. Через несколько лет можно ожидать слияния функций телевизора и ЭВМ, а это потребует пропускных способностей от магистральных каналов на уровне 0,1-10 Гбит/с. Широкополосность каналов, приходящих в каждый семейный дом составит 1-10 Мбит/с, что позволит реализовать видео-телефонию, цифровое телевидение высокого разрешения, доступ к централизованным информационным службам и многое другое. Уже существующие оптоволоконные системы обеспечивают и в 10 раз большую пропускную способность. Можно предположить и появление локальных сетей внутри жилища. Такие сети способны взять под контроль кондиционирование воздуха, безопасность дома в самом широком смысле этого слова, например, оповещение о нежелательном вторжении, пожаре или возможном землетрясении (в сейсмически опасных районах), появление вредных примесей в воздухе. Такая система разбудит хозяина в указанное время, подогреет завтрак, напомнит о предстоящих делах на день, запросит и предоставит хозяину свежий прогноз погоды и справку о состоянии дорог, своевременно сделает заказ на авиабилет и т.д. Все это технологически возможно уже сегодня, пока относительно дорого, но цены весьма быстро падают. Примером может служить сеть CAN, разработанная для сбора данных и управления автомобилем. Стремительное расширение сети Интернет не имеет аналогов в истории, так что любой самый фантастический прогноз в этой области может сбыться.
Протоколы Интернет (TCP/IP) существуют уже около 30 лет. Требования к телекоммуникационным каналам и услугам выросли, и этот набор протоколов не удовлетворяет современным требованиям. Появляются новые протоколы Delta-t (для управления соединением), NetBLT (для передачи больших объемов данных), VMTP (для транзакций; RFC-1045) и XTP для повышения эффективности передачи данных (замена TCP), блоки протоколов для работы с мультимедиа (RTP, RSVP, PIM, ST-II и пр.), но, безусловно, наиболее революционные преобразования вызовет внедрение IPv6.
Виды платежа
11. Виды платежа
11.1. Определения и выбор вида платежа
Одной из ключевых черт IOTP является возможность для продавца предложить список видов платежа, чтобы покупатель мог сделать выбор. Ниже рассматриваются:
определения платежных инструментов и видов платежа в контексте IOTP. Вводятся опционные категории видов оплаты "Dual Brand" или "поощрительный вид платежа", идентификация и выбор поощрительного вид платежа, который предлагает покупателю некоторые дополнительные выгоды, например скидку. Это означает, что и продавец и покупатель должны быть способны корректно идентияицировать, какой из допустимых поощрительных видов платежа использован.11.1.1. Определение платежного инструмента
Платежный инструмент является средством, с помощью которого покупатель платит за товар или услуги, предлагаемые продавцом. Это может быть, например:
кредитная карта, такая как MasterCard или Visa; дебитная карта типа MasterCard Maestro; смарт карта, базирующаяся на системе электронных платежей, такой как Mondex, GeldKarte или Visa Cash; программа, базирующаяся на системе платежей типа CyberCash или DigiCash.Большинство платежных инструментов имеют номер, обычно это номер счета, по которому можно идентифицировать платежный инструмент.
11.1.2. Определение вида платежа
Вид платежа часто представляет собой марку, которая идентифицирует конкретный тип платежного инструмента. Список видов платежа представляет собой опции, которые предоставляются продавцом покупателю и из которых покупатель делает свой выбор. Каждый вид платежа может иметь разных кассиров. Среди примеров вида платежа:
платежные ассоциации и платежные системы частных фирм, например MasterCard, Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, и т.д.. поощрительные виды платежа (смотри ниже). Сюда входят:| - store brands, где платежный инструмент предоставляется покупателю конкретным продавцом, например Walmart, Sears или Marks and Spencer (UK) | |
| - совмещенные виды платежа, например American Advantage Visa, где организация использует свой собственный вид платежа обычно в сочетании с платежами рассчетной ассоциации. |
11.1.3. Определение двойственного вид платежа (Dual Brand)
Двойственный вид платежа ( Dual Brand) означает, что отдельный платежный инструмент может использоваться так, как если бы это были два отдельных вида платежа. Например, может существовать одна японская карта "UC" (MasterCard), которую можно использовать как UC-карту или как обычную MasterCard. Виды платежа через UC-карту и MasterCard могут иметь своих собственных, отличных друг от друга Кассиров. Это означает, что:
продавец рассматривает, например,"UC" и "MasterCard" как два вида платежа, когда предлагает список видов платежа покупателю, покупатель выбирает вид платежа, например, "UC" или "MasterCard, клиент приложения определяет, какой платежный инструмент подходит для выбранного вида платежа и выбирает, возможно с помощью самого пользователя, оптимальный платежный инструмент. Двойственные виды платежа не требуют какого-то специального обслуживания продавцом и, следовательно, не нужно как-то выделять эти виды платежа в DTD. Это происходит потому, что в той части, которая касается продавца, каждый вид платежа в двойственном виде платежа рассматривается как независимый. Только покупатель должен находить соответствие между предлагаемым видом оплаты и имеющимся двойственным платежным инструментом.
11.1.4. Определение стимулирующего вида оплаты
Поощрительный вид оплаты предполагает, что если покупатель им воспользуется, то он получит какие-то дополнительные выгоды. Эти выгоды могут быть получены двумя путями:
во время покупки. Например, если покупатель платит с помощью "Walmart MasterCard" через сервер Walmart, то он может получить скидку в 5%, это означает, что покупатель в действительности платит меньше, от эмитента платежного средства (карты), когда платеж появляется в ведомости. Например, процент за каждую операцию может быть понижен при частом использовании, основываясь на суммарой величине платежей с использованием данного платежного инструмента. Заметим, что:
первый пример (получение выгоды в момент покупки), требует чтобы:
| - Покупатель информируется о выгоде, которую он может получить при выборе данного вида платежа; | |
| - если вид платежа выбран, продавец изменяет соответствующие компоненты IOTP в отклике Offer, чтобы правильно отразить сумму, которую следует оплатить. |
Имеется две проблемы, которые нужно решить при идентификации поощрительных видов платежа:
как продавец или кассир идентифицирует поощрительный вид оплаты, используемый в момент покупки; как покупатель надежно идентифицирует поощрительный вид оплаты в списке видов платежа, представленном продавцом. 11.1.5.1. Идентификация поощрительных видов платежа Продавцом/Кассиром
Правильная идентификация того, что покупатель воспользовался поощрительным видом платежа, крайне важно, так как покупатель может объявить, что он имеет право на скидку, которая действует для поощрительного вида платежа, в то время как в действительности это не так. Здесь возможны два подхода:
использовать некоторую возможность платежного инструмента или метода, чтобы идентифицировать вид используемого платежа. Например, для данного вида платежа может использоваться сертификат SET, если он доступен, или использовать номер платежного инструмента (карты), чтобы получить информацию о платежном инструменте, например, в базе данных эмитента, чтобы узнать является ли данный вид платежа льготным. Заметим, что:
первый вариант предполагает доступность SET. второй – возможен, если продавец или кассир имеют доступ к базе данных эмитента карты. IOTP не предоставляет продавцу информации о платежном инструменте (напр., карте или номере счета).
Эти данные посылаются кассиру в качестве части инкапсулированного платежного протокола. Это означает, что:
Продавец будет вынужден предположить, что выбранный платежный инструмент был льготным видом платежа, или Кассир будет вынужден проверить, что платежный инструмент соответствовал льготному виду платежа, платеж аннулируется, если это не так. Проверка кассиром, является ли платеж льготным, возможна, если кассир совмещает функции и эмитента карты.
11.1.5.2. Выбор Покупателем льготных видов платежа
Существует два способа, как покупатель может выбрать правильно льготный вид платежа:
Покупатель визуально выбирает логотип для льготного вида платежа из числа предложенных продавцом, приложение покупателя выбирает зарегистрированный код льготного платежа из списка видов платежа, предложенного продавцом. В последнем случае, код покупателя должен совпадать с кодом из списка продавца, в противном случае соответствие не будет зарегистрировано. Способы, которыми программа IOTP покупателя может получить такой код, включают:
Покупатель непосредственно вводит этот код. Это располагает к ошибкам и неудобно для клиента, кроме того покупателю надо как-то передать этот код. Этот подход не рекомендуется, Используется один из идентификаторов вида платежа, определенных в IOTP и предварительно загруженных в приложение покупателя, Используется некоторая информация, содержащаяся в программе, или другие данные, связанные с платежным инструментом. Это может быть:
| - сертификат SET для видов платежа, которые используют этот протокол оплаты; | |
| - код предоставляется платежной программой, которая работает с конкретным методом оплаты, это может быть приложимо к, например, GeldKarte, Mondex, CyberCash и DigiCash, |
Рекомендации для Id видов платежа в программе покупателя
Новые Id видов платежа выдаются в соответствии с процедурой, заданной IANA (смотри раздел 12).
Рекомендуется, чтобы разработчики приложений IOTP покупателя (напр., платежных программ) обеспечивали предварительную загрузку текущего набора идентификаторов вида платежа и предлагали средства пополнения этого списка.
11.2. Примеры видов платежа Данный пример содержит три образца XML для компонента списка видов платежа:
вариант с просой кредитной карточкой; список видов платежей, базирующихся на кредитной карте, включая льготные виды платежа, и список видов платежа, базирующийся на комплексных электронных деньгах. 11.2.1. Простой пример, базирующийся на кредитной карте
Этот простой пример включает в себя:
только основные виды платежей с помощью кредитной карты; одну цену и одну валюту; одного Кассира и один платежный протокол. <BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase book including s&h'
PayDirection='Debit' >
<Brand ID ='M1.30' BrandId='MasterCard' BrandName='MasterCard Credit'
BrandLogoNetLocn='ftp://otplogos.mastercard.com/mastercardcredit'
ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M.31' BrandId='Visa' BrandName='Visa Credit'
BrandLogoNetLocn='ftp://otplogos.visa.com/visacredit' ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M1.32' BrandId='AmericanExpress' BrandName='American Express'
BrandLogoNetLocn='ftp://otplogos.amex.com' ProtocolAmountRefs ='M1.33' >
</Brand >
<ProtocolAmount ID ='M1.33' PayProtocolRef='M1.35' CurrencyAmountRefs='M1.34'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.34' Amount='10.95' CurrCode='USD'/>
<PayProtocol ID ='M1.35' ProtocolId='SCCD1.0' ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
</PayProtocol>
</BrandList>
11.2.2. Список платежей с помощью кредитной карты, включая льготные платежи
Пример списка видов платежей с помощью кредитной карты представлен ниже.
Он включает в себя:
два обычных вида платежа через кредитную карту и два льготных вида платежа. два платежных протокола:
| - SET (Secure Electronic Transactions) смотри [SET] и | |
| - SCCD (Secure Channel Credit Debit) смотри [SCCD]. |
<Brand ID ='M1.3' BrandId='MasterCard' BrandName='MasterCard Credit'
BrandLogoNetLocn='ftp://otplogos.mastercard.com' ProtocolAmountRefs='M1.7 M1.8'>
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:'>
</ProtocolBrand>
</Brand>
<Brand ID ='M1.4' BrandId='Visa' BrandName='Visa Credit'
BrandLogoNetLocn='ftp://otplogos.visa.com' ProtocolAmountRefs='M1.7 M1.8'>
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='Visa:'>
</ProtocolBrand>
</Brand>
<Brand ID ='M1.5' BrandId='BritishAirwaysMC' BrandName='British Airways MasterCard'
BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk'
BrandNarrative='Double air miles with British Airways MasterCard'
ProtocolAmountRefs ='M1.7 M1.8' >
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:BA'>
</ProtocolBrand>
</Brand >
<Brand ID ='M1.6' BrandId='Walmart' BrandName='Walmart Store Card'
BrandLogoNetLocn='ftp://otplogos.walmart.com'
BrandNarrative='5% off with your Walmart Card on purchases over $150'
ProtocolAmountRefs='M1.8'>
</Brand>
<ProtocolAmount ID ='M1.7' PayProtocolRef='M1.10' CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<ProtocolAmount ID ='M1.8' PayProtocolRef='M1.11' CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<CurrencyAmount ID ='M1.9' Amount='157.53' CurrCode='USD'/>
<PayProtocol ID ='M1.10' ProtocolId='SET1.0'
ProtocolName='Secure Electronic Transaction Version 1.0'
PayReqNetLocn='http://www.example.com/etill/set1' >
<PackagedContent Transform="BASE64">
8ueu26e482hd82he82
</PackagedContent>
</PayProtocol>
<PayProtocol ID ='M1.11' ProtocolId='SCCD1.0'
ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
<PackagedContent Transform="BASE64">
82hd82he8226e48ueu
</PackagedContent>
</PayProtocol>
</BrandList>
11.2.3. Пример выбора вида платежа
Для оплаты через ' British Airways' MasterCard для выше приведенного варианта и платежного протокола SET список вида платежа будет иметь вид:
<BrandSelection ID='C1.2' BrandListRef='M1.3' BrandRef='M1.5' ProtocolAmountRef='M1.7'
CurrencyAmountRef='M1.9' >
</BrandSelection>
11.2.4. Список видов платежа, базирующихся на комплексных электронных деньгах
Ниже представлен достаточно сложный пример, который включает в себя:
платежи, использующие Mondex, GeldKarte, CyberCash или DigiCash; в валютах, в список которых входят доллары США, британские фунты, итальянские лиры, немецкие марки и канадские доллары; скидку на цену, если платеж выпонен через Mondex, используя британские фунты или американские доллары и более одного Кассира для случаев использования Mondex или CyberCash; поддержка более чем одной версии CyberCash для платежного протокола CyberCoin. <BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Company report on XYZ Co'
PayDirection='Debit'>
<Brand ID ='M1.13' BrandId='Mondex' BrandName='Mondex Electronic Cash'
BrandLogoNetLocn='ftp://otplogos.mondex.com' ProtocolAmountRefs='M1.17 M1.18'>
</Brand>
<Brand ID ='M1.14' BrandId='GeldKarte' BrandName='GeldKarte Electronic Cash'
BrandLogoNetLocn='ftp://otplogos.geldkarte.co.de' ProtocolAmountRefs='M1.19'>
</Brand>
<Brand ID ='M1.15' BrandId='CyberCoin' BrandName='CyberCoin Eletronic Cash'
BrandLogoNetLocn='http://otplogos.cybercash.com' ProtocolAmountRefs ='M1.20'>
</Brand >
<Brand ID ='M1.16' BrandId='DigiCash' BrandName='DigiCash Electronic Cash'
BrandLogoNetLocn='http://otplogos.digicash.com'
BrandNarrative='5% off with your Walmart Card on purchases over $150'
ProtocolAmountRefs='M1.22'>
</Brand>
<ProtocolAmount ID ='M1.17' PayProtocolRef='M1.31'
CurrencyAmountRefs='M1.25 M1.29'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.18' PayProtocolRef='M1.32'
CurrencyAmountRefs='M1.26 M1.27 M1.28 M1.30'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.19' PayProtocolRef='M1.35' CurrencyAmountRefs='M1.28'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.20' PayProtocolRef='M1.34 M1.33'
CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.21' PayProtocolRef='M1.36'
CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.23' Amount='20.00' CurrCode='USD'/>
<CurrencyAmount ID ='M1.24' Amount='12.00' CurrCode='GBP'/>
<CurrencyAmount ID ='M1.25' Amount='19.50' CurrCode='USD'/>
<CurrencyAmount ID ='M1.26' Amount='11.75' CurrCode='GBP'/>
<CurrencyAmount ID ='M1.27' Amount='36.00' CurrCode='DEM'/>
<CurrencyAmount ID ='M1.28' Amount='100.00' CurrCode='FFR'/>
<CurrencyAmount ID ='M1.29' Amount='22.00' CurrCode='CAD'/>
<CurrencyAmount ID ='M1.30' Amount='15000' CurrCode='ITL'/>
<PayProtocol ID ='M1.31' ProtocolId='MXv1.0'
ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankus.com/etill/mx' >
</PayProtocol>
<PayProtocol ID ='M1.32' ProtocolId='MXv1.0'
ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankuk.com/vserver' >
</PayProtocol>
<PayProtocol ID ='M1.33' ProtocolId='Ccashv1.0' ProtocolName='CyberCoin Version 1.0'
PayReqNetLocn='http://www.cybercash.com/ccoin' >
</PayProtocol>
<PayProtocol ID ='M1.34' ProtocolId='CCashv2.0' ProtocolName='CyberCoin Version 2.0'
PayReqNetLocn='http://www.cybercash.com/ccoin' >
</PayProtocol>
<PayProtocol ID ='M1.35' ProtocolId='GKv1.0' ProtocolName='GeldKarte Version 1.0'
PayReqNetLocn='http://www.example.com/pgway'>
</PayProtocol>
<PayProtocol ID ='M1.36' ProtocolId='DCashv1.0'
ProtocolName='DigiCash Protocol Version 1.0'
PayReqNetLocn='http://www.example.com/digicash' >
</PayProtocol>
</BrandList>
Вложение пакетов Интернет в Ethernet- и IEEE пакеты
Рисунок 4.1.1.3.5. Вложение пакетов Интернет в Ethernet- и IEEE 802 пакеты
LLC - управление логической связью (logical link control); DSAP = 0xaa (destination service access point) - поле адреса доступа к службе получателя; SSAP = 0xaa (source service access point) - поле адреса доступа к службе отправителя; SNAP - протокол доступа к субсетям (subnetwork access protocol). PAD - поле заполнитель. В общем случае форматы полей DSAP и SSAP имеют вид, показанный на Рисунок 4.1.1.3.6 I/G = 0 - индивидуальный адрес, I/G =1 - групповой адрес; D - бит адреса службы места назначения, S - бит адреса службы отправителя; C/R =0 - команда, C/R =1 - подтверждение.
Открытый торговый протокол Интернет определяет
2. Введение
Открытый торговый протокол Интернет определяет некоторое число различных операций IOTP:
Покупка. Осуществляет предложение, оплату и опционно доставку. Возврат. Производит возврат платежа для покупки, выполненной ранее. Обмен ценностями. Включает в себя два платежа, наприммер в случае обмена валют. Аутентификация. Производит проверку для организации или частного лица – являются ли они тем, за кого себя выдают. Отзыв платежа. Осуществляет отзыв электронного платежа из финансового учрежденрия. Депозит. Реализует депозит средств в финансовом учреждении. Запрос. Выполняет запрос состояния операции IOTP, которая находится в процессе реализации, или уже выполнена. Пинг. Простой запрос одного приложения IOTP с целью проверки, функционирует ли другое приложение IOTP. Эти операции считаются базовыми, позднее могут быть определены другие операции IOTP. Каждая из перечисленных выше операций IOTP включает в себя:
Некоторое число организаций, выполняющих торговую функцию и Набор торговых обменов. Каждый торговый обмен включает в себя обмен данными между торговыми ролями в форме набора торговых компонентов. 2.1. Торговые роли
Торговые роли идентифицируют различные обязанности, которые может выполнять организации в процессе торговли. В IOTP используется пять торговых ролей, которые проиллюстрированы на Рисунок .1.
Введение (общие принципы построения сетей)
1 Введение (общие принципы построения сетей)
