Открытый торговый протокол Интернет определяет некоторое число различных операций IOTP:

Покупка. Осуществляет предложение, оплату и опционно доставку.

Возврат. Производит возврат платежа для покупки, выполненной ранее.

Обмен ценностями. Включает в себя два платежа, наприммер в случае обмена валют.

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

Отзыв платежа. Осуществляет отзыв электронного платежа из финансового учрежденрия.

Депозит. Реализует депозит средств в финансовом учреждении.

Запрос. Выполняет запрос состояния операции IOTP, которая находится в процессе реализации, или уже выполнена.

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

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

Некоторое число организаций, выполняющих торговую функцию и

Набор торговых обменов. Каждый торговый обмен включает в себя обмен данными между торговыми ролями в форме набора торговых компонентов.

2.1. Торговые роли
Торговые роли идентифицируют различные обязанности, которые может выполнять организации в процессе торговли. В IOTP используется пять торговых ролей, которые проиллюстрированы на Рисунок .1.

А Специальные ip-адреса

Рисунок 4.1.1.3.2.а. Специальные ip-адреса


IP-адрес имеет Интернет- и местную секции, первая характеризует место (организацию, сеть или даже группу сетей), вторая - конкретную ЭВМ. Местная секция адреса может быть разделена на части, характеризующие локальную сеть и конкретную ЭВМ (Рисунок 4.1.1.3.3).

Базовая транзакция аутентификации

Рисунок .24. Базовая транзакция аутентификации

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

когда имеет место базовая транзакция аутентификации на ранней фазе сессии, тогда, например финансовая организация может:

	- сформировать безопасный канал связи с покупателем (напр., используя [SSL/TLS]);
	- аутентифицировать покупателя, используя базовую транзакцию аутентификации и затем;
	- предоставить покупателю доступ к информации и другим услугам с конфиденциальностью, с которой они общаются с добросовестными клиентами.

как средство предоставления продавцу компонента Organisation, который содержит информацию о покупателе и торговой роли DelivTo;

предоставление возможности аутентифицировать кассира до начала процедуры платежа.

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

опционный документальный обмен аутентификации (смотри раздел 9.1.1);

документальный обмен предложения (смотри раздел 9.1.2) и

документальный обмен платежа (смотри раздел 9.1.3).

Способ, с помощью которого эти документальные обмены могут взаимодействовать, показан на Рисунок .25.

Базовая транзакция депозита

Рисунок .25. Базовая транзакция депозита

Смотри раздел 9.1.12, чтобы определить какие комбинации документальных обменов применимы к конкретным транзакциям. Заметим, что:

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

Продавец (финансовая организация) может использовать результаты аутентификации не только для идентификации покупателя, но и счета, на котором следует разместить депозит. Если не удается идентифицировать один счет, используются другие средства. Например:

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

Базовая IOTP-транзакция депозита без аутентификации может быть использована:

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

9.1.8. Базовая транзакция покупки
Базовая транзакция покупки поддерживает покупку товаров или услуг с применением любых платежных методов. Она включает в себя следующие документальные обмены:

опционный документальный обмен аутентификации (смотри раздел 9.1.1)

документальный обмен предложения (смотри раздел 9.1.2)

или:

	- документальный обмен платежа ge (смотри раздел 9.1.3), за которым следует
	- документальный обмен доставки (смотри раздел 9.1.4)

только документальный обмен платежа или

комбинированный документальный обменплатежа и доставки (смотри раздел 9.1.5).

Способы, какими эти документальные обмена могут комбинироваться показаны на Рисунок .26.

Базовая транзакция обмена ценностями

Рисунок .29. Базовая транзакция обмена ценностями

Базовая транзакция обмена ценностями осуществляется в двух вариантах:

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

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

В выше приведенном примере фигурирует роль продавца, хотя организацией, выполняющей обмен ценностями может быть банк или какая-то другая финансовая организация. Это потому, что банк выполняет здесь роль продавца, направляя покупателю предложение, которое он может принять или отвергнуть.
Блоки TPO и отклика Offer могут быть объединены в одном сообщении, только если содержимое блока отклика Offer не изменяется в результате выбора вида платежа и платежного протокола для обмена ценностями.
Использование подписей, чтобы гарантировать целостность обмена ценностями проиллюстрирована на диаграмме Рисунок .30.

Базовая транзакция отзыва сделки

Рисунок .28. Базовая транзакция отзыва сделки

Заметим, что:

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

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

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

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

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

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

Перенос электронных средств на кредитную карту. Например, первый платеж может быть "dollar SET Payment", использующий кредитную карту, а второй платеж использует кредитную карту Visa Cash и осуществляет электронный перевод в долларах.

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

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

Базовый обмен ценностями использует следующие документальные обмены:

опционный документальный обмен аутентификации (смотри раздел 9.1.1);

документальный обмен предложения (смотри раздел 9.1.2), который определяет детали того, какие суммы и валюты подлежат обмену и

два документальных обмена платежа (смотри раздел 9.1.3), которые осуществляют два реализуемые платежа.

Способы, которыми эти документальные обмены комбинируются друг с другом изображены на Рисунок .29.

Базовая транзакция покупки

Рисунок .26. Базовая транзакция покупки

Чтобы определить, какие комбинации документальных обменов встречаются в каждой из транзакций смотри раздел 9.1.12. 9.1.9. Базовая транзакция возврата денег
Процесс возврата денег обычно состоит из:

запроса возврата, направленного покупателем продавцу, и имеющего целью продемонстрировать:

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

Продавец соглашается (или нет) вернуть деньги. Это может включать некоторые переговоры между покупателем и продавцом, и если продавец согласен,

выполняется возврат денег продавцом покупателю.

Базовая транзакция возврата денег поддерживает субнабор возможностей перчисленных выше, в частности поддерживает:

отдельную аутентификацию покупателя, где используется базовая транзакция аутентификации (смотри раздел 9.1.6)

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

	- опционный документальный обмен аутентификации (смотри раздел 9.1.1)
	- документальный обмен предложения (смотри раздел 9.1.2) и
	- документальный обмен платежа (смотри раздел 9.1.3).

Способы того, как эти документальные обмены взаимодействуют, показаны на Рисунок .27.

Базовая транзакция статусного запроса

Рисунок .32. Базовая транзакция статусного запроса

Блок ссылок транзакции Торговая роль, делающая информационный запрос, должна использовать Id-компонент (смотри раздел 3.3.1), где атрибуты IotpTransId и TransTimeStamp имеют те же значения, что и в Id-компоненте исходной транзакции, объекта запроса. Атрибут IotpTransID в этом компоненте выполняет роль ключа при запросе записей, которые ведет торговая роль. Значение ID-атрибута Id-компонента должно быть отличным от любых других в исходной транзакции (смотри раздел 3.4.1).
Если требуются текущие статусные данные, компонент MsgId, и конкретный ID-атрибут для компонента MsgId должен отличаться от любых других в сообщениях, посланных торговой роли. Блок информационного запроса (смотри раздел 8.12) содержит следующие компоненты:

один компонент типа информационного запроса (смотри раздел 7.18). Он идентифицирует, относится ли запрос к предложению, платежу или доставке.

нуль или один компонент платежной схемы (смотри раздел 7.10). Это нужно для инкапсуляции специфических платежных сообщений.

Блок подписи (информационный запрос)
Если в сообщении, содержащем блок информационного запроса, присутствует блок подписи, тогда он может быть проверен, чтобы определить, авторизован ли этот запрос.
Если присутствует блок подписи информационного запроса (смотри раздел 8.12), то он содержит следующие компоненты:

один компонент Signature (смотри раздел 7.19)

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

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

Покупатели вряд ли будут генерировать запросы, снабженные подписью, но если они это сделают, это не будет считаться ошибкой;

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

С другой стороны, если исходная транзакция, к которой относится запрос, реализована через безопасный канал (напр., [SSL]), тогда разумно предположить, что, если отправитель информационного запроса знает Id-компонент исходного сообщения (включая, например, временную метку), то запрос является подлинным. Блок отклика INQUIRY (смотри раздел 8.13) содержит следующие компоненты:

один компонент Status (смотри раздел 7.16). Этот компонент содержит статусную информацию о запрашиваемой транзакции,

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

Блок SIGNATURE (отклик информационного запроса)

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

Если блок подписи информационного отклика присутствует (смотри раздел 8.13), он содержит следующие компоненты:

один компонент Signature (смотри раздел 7.19)

один или более компонентов Certificate, если они нужны.

Цифровые подписи информационного отклика могут использоваться, только если получатель ожидает прихода подписанных откликов. В данной версии IOTP tэто предполагает предварительное согласование применение цифровых подписей. Это означает, что:

Покупатели вряд ли будут формировать отклики с подписями, хотя, если они это сделают, это не будет ошибкой;

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

9.2.2. Базовая транзакция Ping

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

определить, работает ли приложение IOTP другой торговой роли;

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

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


Торговыми блоками, используемыми транзакцией Ping, являются:

блок запроса Ping (смотри раздел 8.14),

блок отклика Ping (смотри раздел 8.15) и

блок Signature (смотри раздел 8.16).

Сообщения PING

На Рисунок .33 отображен обмен сообщениями прибазовой транзакции Ping.

1.	Приложение IOTP первой торговой роли решает проверить, находится ли в рабочем состоянии соответствующее приложение партнера. Оно генерирует блок запроса Ping, опционный блок подписи и шлет их другой торговой роли.
1 a 2	Запрос PING. IotpMsg: блоки Trans Ref; подписи (опционный); запроса Ping
2.	Вторая торговая роль, которая получает блок запроса Ping, генерирует блок отклика Ping и посылает его отправителю исходного запроса Ping, с блоком подписи, если это требуется.
1 ? 2	Отклик PING. IotpMsg: блоки Trans Ref; подписи (опционный); отклика Ping
3.	Первая торговая роль проверяет блок отклика Ping и выполняет необходимые действия, если это требуется

Базовая транзакция возврата денег

Рисунок .27. Базовая транзакция возврата денег

Базовая транзакция возврата денег без документального обмена аутентификации может использоваться:

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

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

когда аутентификация покупателя осуществлена кассиром в рамках реализации платежного алгоритма.

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

опционный документальный обмен аутентификации (смотри раздел 9.1.1)

документальный обмен предложения (смотри раздел 9.1.2) и

документальный обмен платежа (смотри раздел 9.1.3).

Способы, какими эти документальные обмены могут комбинироваться показаны на Рисунок .28.

Базовые сообщения транзакции Ping

Рисунок .33. Базовые сообщения транзакции Ping

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

компонентов Organisation, которые идентифицируют себя и предполагаемого получателя блока запроса Ping;

блок подписи, который гарантирует корректность и целостность запроса Ping.

Получатель запроса Ping таким образом:

знает, кто послал запрос Ping и может следовательно верифицировать подпись запроса;

знает, кто должен генерировать подпись отклика Ping.

Заметим, что запрос Ping:

не влияет на выполнение транзакций;

в отличии от других сообщений IOTP, таких как TPO или статусный запрос, не запускает новых транзакций IOTP.

Все приложения IOTP должны присылать отклики Ping отправителю запросов Ping, сразу по получении.
Базовый запрос IOTP Ping может также содержать опционный блок подписи. Приложение IOTP может, например, использовать блок подписи для проверки того, способен ли получатель этого запроса формировать и верифицировать цифровые подписи.
Для каждой транзакции Ping, каждая роль IOTP может устанавливать различные транспортные сессии.
Любая торговая роль IOTP может посылать запрос Ping любой другой торговой роли. Сообщение Ping имеет свой собственный IotpTransId, который отличается от соответствующего параметра других транзакций.
Блок ссылок транзакции
IotpTransId транзакции Ping должен быть уникальным и отличать данную транзакцию от любых других.
Блок запроса PING
Если транзакция Ping является анонимной, тогда в блок запроса Ping включается компонент no Organisation (смотри раздел 8.7).
Если транзакция Ping не анонимна, то блок запроса Ping содержит компоненты Organisation для:

отправителя блока запроса Ping;

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

Если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping сформировал блок подписи. Блок подписи должен быть верифицирован торговой ролью, которая получила этот запрос Ping.
Блок подписи запроса Ping (смотри раздел 8.16) содержит следующие компоненты:

один компонент Signature (смотри раздел 7.19)

один или более компонентов Certificate, если они требуются.

Блок отклика PING
Блок отклика PING (смотри раздел 8.15) содержит следующие компоненты:

компонент Organisation отправителя сообщения-отклика Ping

Если транзакция Ping не является анонимной, тогда отклик Ping дополнительно содержит:

копии компонентов Organisation, содержащиеся в блоке запроса Ping.

Блок SIGNATURE (отклик PING)
Блок подписи отклика Ping (смотри раздел 8.16) содержит следующие компоненты:

один компонент Signature (смотри раздел 7.19);

один или более компонентов Certificate, если они нужны.

Блок-диаграмма обмена сообщениями платежа и аутентификации

Рисунок .17. Блок-диаграмма обмена сообщениями платежа и аутентификации

Допустимые комбинации документального обмена зависят от конкретного типа транзакции IOTP. Далее рассматриваются методы обработки рабочих ошибок (Business Errors) в процессе документального обмена (смотри раздел 4.2).
9.1.1. Документальный обмен аутентификации
Документальный обмен аутентификации является непосредственной реализацией торгового обмена аутентификации (смотри раздел 2.2.4). Он включает в себя:

o	Аутентификатор организация, которая запрашивает аутентификацию;
o	Аутентифицируемый - организация, которая должна пройти аутентификацию.

Аутентификация состоит из:

Запрос аутентификации, посылаемый аутентификатором аутентифицируемому,

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

Документальный обмен аутентификации предполагает также:

Предоставление аутентифицируемому компонента Organisation, который описывает аутентификатора и

Опционно, предоставление аутентификатору компонента Organisation, который описывает аутентифицируемого.

Запрос аутентификации может быть подписан цифровым образом, что позволяет аутентифицируемому, проверить доверительные параметры (credentials) аутентификатора. IOTP-сообщения, которые используются в таком обмене представлены на Рисунок .18.

1.	Первая организация предпринимает некоторое действие (например, нажимает кнопку на HTML-странице), которое требует аутентификации
1 a 2	Необходимость аутентификации (за пределами протокола IOTP)
2.	Вторая организация генерирует: блок запроса аутентификации, содержащий один или несколько компонентов запроса аутентификации и/или компонент информационного запроса о торговой роли, которые посылаются первой организации
1 ? 2	Запрос TPO & аутентификации. Сообщение IotpMsg: блоки TransRef; Signature (опционно); TPO; запроса аутентификации
3	Запускается приложение IOTP. Если присутствует блок Signature, первая организацияможет использовать проверку параметров доверия (credentials) второй организации. Если все в порядке, первая организация выбирает запрос аутентификации (если присутствует или их более одного), и запускает аутентификационный алгоритм для формирования блока отклика аутентификации. Для генерации компонентов Organisation, если требуется, используетсякомпонент запроса данных о торговой роли. Наконец создается, если нужно, компонент Signature и все компоненты посылаются второй организации для проверки.
1 a 2	Отклик аутентификации. Сообщение IotpMsg: блоки Trans Ref; Signature (опционно) ; Auth Response
4.	Вторая организация проверяет отклик Authentication, сопостовляя его с блоком запроса и убеждаясь, что первая организация именно та, за которую она себя выдает. По результатам проверки первой организации посылается статусный блок аутентификации.
1 ? 2	Состояние аутентификации. Сообщение IotpMsg: блоки Trans Ref; Signature (опционно); Auth Response
5.	Первая организация проверяет статусный блок и, если все в порядке, завершает транзакцию.

Cхема вложения пакетов в TCP/IP (в данном примере в поле тип Ethernet кадра будет записан код )

Рисунок 4.1.1.3.4. cхема вложения пакетов в TCP/IP (в данном примере в поле тип Ethernet кадра будет записан код 0800)


Отдельные сети в Интернет соединяются друг с другом через узловые серверы (gateway, их иногда называют пограничными маршрутизаторами - boarder gateway), расстояние между которыми может измеряться метрами или тысячами километров. В межсетевых обменах также используется принцип вложения так пакеты Ethernet могут вкладываться в пакеты FDDI и т.д.. Прикладные программы также как и все протокольное программное обеспечение уровня Интернет и выше работают только с ip-адресами, в то время как уровень сетевого программного обеспечения работает с физическими сетевыми адресами (так Ethernet использует 48-битные адреса).
Обычно при описании сетей используется терминология 7-уровневой модели ISO ("стек протоколов"). Так уж получилось, но Интернет лишь с определенными натяжками можно описать, придерживаясь этой схемы.
Ethernet инкапсуляция (RFC 894) (размеры полей указаны в байтах)

Цифровые подписи и IOTP

6. Цифровые подписи и IOTP

IOTP может успешно работать без использования цифровых подписей в открытой сетевой среде, но это менее безопасно - смотри 5. Ниже рассматривается использование цифровых подписей для решения различных задач.
6.1. Как IOTP использует цифровые подписи?
В IOTP цифровые подписи используются как:

Компоненты IOTP (смотри раздел 7).

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

идентификатор:

	- того, какая организация сделала подписи;
	- какая организация должна обрабатывать подпись с целью проверки.

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

Дайджесты подписи

Рисунок .10. Дайджесты подписи

Классическим примером того, как одна цифровая подпись подтверждает другую в IOTP, является случай когда Продавец сначала подписывет предложение, формируя подпись отклика предложения, которое позднее подтверждается кассиром с помощью подписи платежной расписки. Таким путем платеж в транзакции IOTP связывается с предложением продавца. Заметим, что один Manifest может соответствовать многим элементам подписи "Value", где каждый элемент значения содержит цифровую подпись того же самого Manifest. Это, в частности, позволяет продавцу согласовать применение различных секретных ключей с кассиром и агентом доставки. Детальные описания компонента подписи содержится в разделе 7.19.
6.1.1. Пример подписи IOTP
Пример использования подписи проиллюстрирован ниже на Рисунок .11, где показано как взаимодействуют различные компоненты и элементы друг с другом.
Для целей иллюстрации была использована базовая торговая транзакция. Применение элементов и атрибутов аналогично для всех типов транзакций IOTP.
Элемент Manifest в компоненте подписи содержит дайджесты TransRefBlock (не покаазан); ID-компонента транзакции (не покаазан); компонентов организаций (Продавца, Кассира, Агента доставки); компонент списка видов платежа; компонент заказа, платежный компонент, компонент доставки и компонент выбора вида платежа (если покупка зависит от вида платежа).

Диалог в локальных сетях и в Интернет

4.5.15 Диалог в локальных сетях и в Интернет


Команды Talk (для SUN), Phone (для VAX/VMS) и другие служат для переговоров двух человек, работающих на одной и той же ЭВМ с удаленных терминалов в реальном масштабе времени. Хотя эти команды и не используют протоколы TCP/IP, они весьма удобны при работе, в частности при отладке новых телекоммуникационных каналов. Вызов осуществляется в соответствии с форматами: Talk bobyshev@ns.itep.ru или Phone , где - имя партнера (его ID, используемое при входе в ЭВМ), с которым вы хотите поговорить. При использовании этих процедур экран делится на две части по вертикали, верхняя часть предназначена для печати текста вызывающего, нижняя часть для его партнера.
Существует версия и Internet-Phone, которая обеспечивает голосовую двухстороннюю связь между пользователями сети. Этот вид услуг примыкает скорее к разновидностям сервиса, описанным в следующей главе. Для обеспечения работы такого канала связи достаточно ЭВМ PC-486SX с частотой 25МГц, памятью 8Мбайт и стандартной аудио-картой. Программы, поддерживающие этот вид сервиса, работают в рамках Windows, Winsock 1.1. При этом вы займете полосу канала шириной 7.7Кбит/c. При установке звуковой VC-платы c сжатием аудио-информации можно ограничить требования на полосу до уровня 6.72Кбит/c. Следует ожидать появления программ и на других платформах и в других средах. Общедоступное программное обеспечение для работы с аудио-версией Phone можно получить через анонимное FTP по адресу ftp.volcaltec.com (используйте ID-пользователя=ftp). Разговаривать можно только с одним партнером одновременно. Возможно совмещение разговора с другими процедурами Internet, что особенно привлекательно при диагностике и отладке каналов и сетевых программ. Internet-Phone контактирует с IRC (Internet Relay Chat, смотри подробнее в следующей главе), что позволяет получить необходимую справочную информацию. Используя возможности IRC, можно выбрать мышкой нужного вам партнера и начать беседовать с ним, если он конечно сидит у ЭВМ, которая оснащена необходимым аппаратным и программным обеспечением.
В рамках этого вида сервиса вы можете обсудить какой-то документ, отображенный на экране терминалов, отмечая нужные места с помощью манипуляторов мышь. Это дает возможность согласовать в реальном масштабе времени текст документа, обсудить элементы конструкции или схемы, не тратя деньги на командировку или на дорогостоящее оборудование для видеоконференций. Бесплатно поболтать с вашим приятелем в Рио-де-Жанейро - это ли не мечта многих россиян?

Если же специального оборудования в вашем распоряжении нет, можно воспользоваться текстовой версией Talk или Phone. Обращение к Talk имеет форму:

talk имя_пользователя [ ttyname ]

Если вы хотите поговорить с кем-то на вашей ЭВМ, достаточно в качестве параметра ввести имя_пользователя (login ID). Если же ваш партнер работает на другой машине, имя адресата может иметь вид: host!пользователь или host.пользователь, или host:пользователь, или пользователь@host, где host - это имя ЭВМ, на которой работает ваш партнер. Последняя форма используется чаще. При необходимости переговорить с человеком, работающем на определенном терминале, следует ввести имя этого терминала (ttyname). При получении запроса Talk выдает на экран следующее сообщение:

Message from TalkDaemon@his_machineattime...
talk: connection requested by ваше_имя@ваша_ЭВМ.
talk: respond with: talk ваше_имя@ваша_ЭВМ

Пользователь, желающий участвовать в диалоге, должен ответить:

talk ваше_имя@ваша_ЭВМ

Когда связь установлена, оба участника диалога могут печатать текст одновременно с отображением обоих текстов в верхней и нижней частях экрана. Нажатие комбинации СTRL-L переписывает заново содержание экрана. Для завершения диалога следует нажать CTRL-Y. Имя ЭВМ адресата можно найти в файле /etc/hosts, а имя терминала в файле /etc/utmp. В процессе общения с использованием терминала возникает проблема - "пальцы не поспевают за мыслью". Традиция англоязычного общения выработала некоторые общепринятые сокращения часто используемых слов и выражений, которые могут облегчить диалог:

Документальный обмен аутентификации

Рисунок .18. Документальный обмен аутентификации

9.1.1.1. Принципы обработки сообщений При получении ссобщения-запроса TPO & Authentication (смотри ниже), аутентифицируемый может:

сформировать и послать аутентификатору сообщение-отклик аутентификации или

обнаружив ошибку в запросе аутентификации, послать аутентификатору блок Cancel, содержащий компонент Status аутентификации с атрибутом StatusType и/или ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равным: AutEeCancel, NoAuthReq, TradRolesIncon или Unspecified.

Получив сообщение-отклик Authentication (смотри ниже), аутентификатор должен в ответ послать сообщение состояния аутентификации, содержащее блок Status с компонентом Status, где StatusType = Authentication и:

атрибут ProcessState компонента Status = CompletedOk, в случае успешного завершения проверки, или

атрибут ProcessState = Failed, а атрибут CompletionCode =: AutOrCancel, AuthFailed или Unspecified, в случае неудачи аутентификации,

Получив сообщение состояния аутентификации (смотри ниже), аутентифицируемый должен проверить компонент Status в блоке состояния. Если он указывает на:

o	успех аутентификации, тогда аутентифицируемый должен сделать следующее:
-	продолжить следующий шаг транзакции, частью которой является документальный обмен аутентификации, или
-	индицировать отказ продолжения транзакции путем посылки аутентификатору блока Cancel, содержащего компонент Status с атрибутом аутентификации StatusType, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) = AutEeCancel.
o	аутентификация не прошла, тогда аутентифицируемый должен быть оповещен о неудаче, а процесс остановлен.

Если аутентификатор получает от Покупателя сообщение IOTP, содержащее блок Cancel, тогда аутентифицируемый может обратиться к сетевому узлу CancelNetLocn, специифицированному элементом торговой роли в компоненте Organisation для аутентификатора, указанного в блоке опций торгового протокола.
9.1.1.2. Сообщение запроса аутентификации и TPO

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:

блок опций торгового протокола (смотри раздел 8.1),

блок запроса Authentication (смотри раздел 8.4) и

опционный блок Signature (смотри раздел 8.16).

Каждый из них описан ниже.

Блок опций торгового протокола

Блок опций торгового протокола (смотри раздел 8.1) должен содержать следующие торговые компоненты:

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

один компонент Organisation (смотри раздел 7.6), который описываетаутентификатор. Компонент торговой роли организации должен указывать на роль, какую играет аутентификатор в данной сделке, например Пордавец или Покупатель.

Блок запроса аутентификации

Блок запроса аутентификации (смотри раздел 8.4) должен содержать следующие торговые компоненты:

один компонент запроса аутентификации (смотри раздел 7.2), и

Блок подписи (Запрос аутентификации)

Если запрос аутентификации был снабжен цифровой подписью, то должен быть включен блок Signature. Он содержит дайджесты следующих XML-элементов:

o	блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит информацию, описывающую сообщение и транзакцию;
o	Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;
o	следующие компоненты блока TPO:
	- компонент протокольных опций;
	- компонент Organisation.

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

	- компонент запроса аутентификации
	- компонент информационного запроса о торговой роли

9.1.1.3. Сообщение-отклик аутентификации IOTP

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:

блок отклика Authentication (смотри раздел 8.5) и

опционный блок Signature (смотри раздел 8.16).

Блок отклика AUTHENTICATION
Блок отклика аутентификации должен содержать следующие торговые компоненты:

один компонент отклика аутентификации (смотри раздел 7.3)

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

Блок SIGNATURE (Отклик аутентификации)


Если элемент Algorithm ( смотри раздел 12) компонента запроса аутентификации содержащийся в блоке запроса аутентификации, указывает, что отклик аутентификации должен содержать цифровую подпись, тогда блок Signature должен быть включен в то же сообщение, где размещается блок отклика аутентификации. Компонент Signature содержит элементы дайджестов для следующиз XML-элементов:

блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит информацию, описывающую сообщение и транзакцию IOTP;

Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;

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

	- компонент запроса аутентификации;
	- компонент информационного запроса о торговой роли;

компоненты Organisation, содержащиеся в блоке отклика аутентификации.

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

9.1.1.4. Сообщение состояния аутентификации

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:

блок состояния аутентификации (смотри раздел 8.5) и

опционный блок Signature (смотри раздел 8.16).

Блок состоояния аутентификации

Блок состоояния аутентификации (смотри раздел 8.6) должен содержать следующие торговые компоненты:

один компонент Status (смотри раздел 7.16) с атрибутом ProcessState = CompletedOk.

Блок SIGNATURE (состояние аутентификации)

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

блок ссылок транзакции (смотри раздел 3.3) для сообщения, которое содержит информацию, описывающую сообщение IOTP и транзакцию;

Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;

Следующие компоненты блока состояния аутентификации:

- компонент Status (смотри раздел 7.16).

Если за документальным обменом аутентификации следует документальный обмен предложения (Offer) (смотри раздел 9.1.2), тогда блок состояния аутентификации и блок подписи (состояние аутентификации) могут объединяться с:

сообщение TPO (смотри раздел 9.1.2.3), или

сообщение TPO и отклик Offer (смотри раздел 9.1.2.6)

9.1.2. Обмен документами предложения

Обмен документами предложения oвстречается в двух формах:

обмен предложения, зависящего от вида платежа. Где содержимое предложения, напр., детали заказа, сумма, детали доставки, и т.д., зависят от вида платежа и протокола, выбранных покупателем;

обмен предложения, не зависящего от вида платежа. Где содержимое предложения не зависит от выбранного вида платежа или протокола.

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

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

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

комонент списка вида платежа посылается покупателю в блоке TPO;

Покупатель выбирает вид платежа, платежный протокол и опционно вид валюты из компонента видов платежа;

Покупатель посылает выбранные вид платежа, протокол и валюту продавцу в блоке выбора TPO;

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

Это проиллюстрировано на диаграмме ниже (Рисунок .19).

1.	Покупатель решает совершить покупку и посылает продавцу информацию (напр., используя HTML), которая позволяет продавцу сформировать предложение,
C a M	Информация предложения – вне области действия IOTP
2.	Продавец решает, какой платежный протокол, валюту и пр. использовать, помещает эти данные в компонент видов платежа в блоке TPO и посылает покупателю
C ? M	TPO (опции торгового протокола). IotpMsg: блоки Trans Ref Block; TPO
3.	Приложение IOTP запущено. покупатель выбирает вид платежа, платежный протоколи вид валюты. Компонент выбора вида платежа посылается Продавцу.
C a M	Выбор TPO. IotpMsg: блоки Trans Ref Block и выбора TPO
4.	Продавец использует выбранный вид платежа, плптежный протокол, валюту и информацию предложения для формирования блока отклика Offer, содержащего детали транзакции IOTP, включая цену, и т.д., опционно подписывает его и посылает покупателю
C ? M	Отклик OFFER. IotpMsg: блоки Trans Ref, Signature (опционный) и отклика Offer
5.	Покупатель проверяет все ли в порядке в Offer, затем комбинирует компоненты из блоков TPO, выбора TPO и отклика Offer, чтобы сформировать следующее сообщение транзакции, и посылает его вместе с блоком подписи (если таковая нужна) соответствующей торговой роли

… продолжение ...

Документальный обмен платежа и доставки

Рисунок .23. Документальный обмен платежа и доставки

Блоки отклика доставки и платежного отклика могут быть обхединены в одном сообщении только если кассир имеет необходимую информацию, чтобы послать блок отклика доставки. Это вероятно так, если роли продавца, кассира и агента доставки совмещены. Атрибут DelivAndPayResp компонента доставки (смотри раздел 7.13), содержащийся в блоке отклика Offer (смотри раздел 8.3), делается равным True, если блоки отклика доставки и платежного отклика объединены в одном сообщении, и равен False, если блоки отклика доставки и платежного отклика посланы в разных IOTP-сообщениях.
9.1.5.1. Принципы обработки сообщений
Получив сообщение платежного запроса или платежного обмена, кассир должен выполнить некоторые действия по документальному платежному обмену (смотри раздел 9.1.3.1).
Получив сообщение платежного обмена, покупатель также должен выполнить некоторые действия по платежному документальному обмену (смотри раздел 9.1.3.1).
По получении сообщения платежного отклика и отклика доставки транзакция завершена.
Если покупатель получает сообщение IOTP, содержащее блок Cancel, информация, содержащаяся в сообщении должна быть доведена до сведения покупателя и более никаких действий не предпринимается.
Если кассир получает сообщение IOTP, содержащее блок Cancel, тогда покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для кассира.
Если продавец получает сообщение IOTP, содержащее блок Cancel, тогда покупатель должен прервать операцию платежа. В этом случае покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для продавца. Здесь он может предпринять какие-то дальнейшие действия.
9.1.5.2. Сообщение платежного запроса IOTP
Содержимое этого сообщения то же, что и для запроса при платежном документальном обмене (смотри раздел 9.1.3.2).
9.1.5.3. Сообщение платежного обмена IOTP
Содержимое этого сообщения то же, что и для платежного документального обмена (смотри раздел 9.1.3.3).

9.1.5.4. Сообщение платежного отклика и отклика доставки

Содержимое этого сообщения включает в себя:

блок платежного отклика,

опционный блок подписи (платежный отклик) и

блок отклика доставки.

Содержимое блока платежного отклика то же, что и в платежном отклике при платежном документальном обмене (смотри раздел 9.1.3.4).

Блок SIGNATURE (отклик PAYMENT)

Содержимое этого блока то же, что и в блоке Signature (платежный отклик) при платежном документальном обменее (смотри раздел 9.1.3.4).

Содержимое блока отклика доставки то же, что и в блоке отклика доставки при платежном документальном обменее (смотри раздел 9.1.4.3).

9.1.6. Базовая транзакция аутентификации

Базовая транзакция аутентификации может иметь место в любое время между торговыми ролями, вовлеченными в сделку IOTP. Это означает, что она может иметь место:

перед другой транзакцией IOTP;

одновременно с другой транзакцией;

независимо от каких-либо других транзакций.

Базовая транзакция IOTP аутентификации предполагает обмен аутентификационными документами (смотри раздел 9.1.1) как это показано на Рисунок .24.

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

Рисунок .19. Документальный обмен предложения, зависимого от вида платежа

Покупатель идентифицирует документальный обмен предложения, зависимого от вида платежа, с помощью отсутствия блока отклика Offer в первом сообщении IOTP. Обработка сообщений
Получив сообщение TPO (смотри ниже), Покупатель может:

сформировать и послать сообщение выбора TPO Продавцу, или

индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с атрибутом StatusType = Offer, ProcessState = Failed и CompletionCode (смотри раздел 7.16.4) равным: ConsCancelled или Unspecified.

Получив сообщение выбора TPO (смотри ниже), Продавец может:

сформировать и послать сообщение отклика Offer Покупателю, или

индицировать сбой, послав Покупателю блок Cancel, содержащий компонент Status с атрибутом StatusType = Offer, ProcessState = Failed и CompletionCode (смотри раздел 7.16.4) равным: MerchCancelled или Unspecified.

Получив сообщение отклика Offer (смотри ниже), Покупатель может:

сформировать и послать следующее сообщение транзакции IOTP соответствующей торговой роли. Это зависит от типа транзакции, или

индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с StatusType = Offer, ProcessState =of Failed и CompletionCode (смотри раздел 7.16.4) равным: ConsCancelled или Unspecified.

Если продавец получает сообщение IOTP, содержащее блок Cancel, покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный в элементе торговой роли компонента Organisation продавца. Если покупатель получает сообщение, содержащее блок Cancel, тогда информация, содержащаяся в сообщении должна быть доведена до сведения покупателя.
9.1.2.2. Документальный обмен предложения, независимого от вида платежа
В документальном обмене предложения, независящего от вида платежа, блоки TPO и отклика Offer посылаются вместе от продавца к покупателю, т.e. имеется одно сообщение IOTP, которое содержит блоки TPO и отклика Offer.
Обмен сообщениями проиллюстрирован на Рисунок .20 ниже:

1.	Покупатель решает заключить сделку и посылает продавцу информацию (напр., используя HTML), которая позволяет ему подготовить предложение,
C a M	Информация предложения – вне пределов действия IOTP
2.	Продавец решает, какой применить платежный протокол и валюту, помещает эти данные в компонент списка видов платежа в блок TPO, формирует отклик Offer, содержащий некоторые детали транзакции, например цену, опционно подписывает эту информацию и посылает покупателю
C ? M	Отклик TPO & OFFER. IotpMsg: блоки Trans Ref; Signature; TPO; отклика Offer
3.	Запускается приложение IOTP. Покупатель выбирает вид платежа, платежный протокол, валюту. Записывает свой выбор в компонент выбора вида платежа, проверяет предложение и, если все в порядке, комбинирует компонент выбора вида платежа и информацию из блоков TPO Block и отклика Offer, чтобы сформировать следующее сообщение транзакции и послать его соответствующей торговой роли.

… Продолжение ...

Допустимые комбинации документальных обменов

Рисунок .31. Допустимые комбинации документальных обменов

1) Если первое сообщение IOTP транзакции содержит запрос аутентификации, то:

	a) Транзакция IOTP содержит документальный обмен аутентификации (смотри раздел 9.1.1). (Замечание 1)
	b) Если последнее сообщение документального обмена аутентификации содержит блоки TPO и отклика предложения, тогда:
		i) Транзакция IOTP включает документальный обмен предложения, независимый от вида платежа (смотри раздел 9.1.2.2). (Замечание 2)
	c) В противном случае, если последнее сообщение аутентификационного обмена содержит блок TPO, но не содержит блока отклика предложения, тогда:
		i) Сообщение IOTP содержит документальный обмен предложения, зависимый от вида платежа (смотри раздел 9.1.2.1). (Замечание 2)
	d) В противном случае (сообщение состояния аутентификации документального обмена не содержит ни блока TPO ни блока отклика предложения).
		i) Транзакция IOTP содержит только документальный обмен аутентификации. (Замечание 3)

2) В противном случае (отсутствие запроса аутентификации в первом сообщении IOTP):

	e) Транзакция IOTP не включает в себя документальный обмен аутентификации (Замечание 2)
	f) Если первое сообщение содержит блок отклика предложения, тогда:
		i) Транзакция IOTP содержит документальный обмен предложения, независимый от вида платежа (Замечание 2)
	g) В противном случае (отсутствие блока отклика предложения в первом сообщении):
		i) Транзакция IOTP включает документальный обмен предложения, зависимый от вида платежа (Замечание 2)

3) Если блок отклина предложения присутствует в каком-либо сообщении IOTP, тогда:

	h) Если блок отклика предложения содержит компонент доставки, тогда:
		i) Если атрибут DelivAndPayResp компонента доставки равен “Истинно”, то компонент доставки делается равной “Истинно”, тогда:
			(1) Транзакция IOTP состои из документальных обменов платежа и доставки (смотри раздел 9.1.5) (Замечание 4)
		ii) В противном случае (атрибут DelivAndPayResp компонента доставки делается равным “Ложно”)
			(1) Транзакция состоит из документального обмена платежа (смотри раздел 9.1.3), за которым следует обмен доставки (смотри раздел 9.1.4) (Замечание 4)
	i) В противном случае (блок отклика предложения не содержит компонента доставки )
		i) если блок отклика предложения содержит только один компонент платежа, тогда:
			(1) Транзакция IOTP содержит только один документальный обмен платежа (Замечание 5)
		ii) если блок отклика Offer содержит компонент платежа, тогда:
			(1) Транзакция IOTP включает в себя два документальных платежных обмена. Атрибут StartAfter компонента платежа используется для индикации того, какой платеж происходит первым. (Замечание 6)
		iii) если блок отклика Offer не содержит ни одного или имеет более двух платежных компонентов, то имеет место ошибка
4) В противном случае (отсутствие блока отклика Offer) имеет место ошибка.

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

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

9.2. Инфраструктурные транзакции

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

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

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

9.2.1. Базовая транзакция запроса состояния транзакции IOTP

Базовая транзакция запроса состояния предоставляет информацию о состоянии существующей или завершившейся транзакции IOTP. Базовая транзакция запроса состояния использует следующие торговые блоки:

торговый блок информационного запроса (смотри раздел 8.12),

торговый блок информационного отклика (смотри раздел 8.13)

опционный блок подписи (смотри раздел 8.16).

Запросы состояния транзакции IOTP могут производиться по разным причинам. Например:

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

определить продавцу, завершен ли платеж, доставка и т.д.. Например, покупатель может объявить, что платеж произведен, но нет платежной расписки, подтверждающей это утверждение. Если продавец делает запрос кассиру, то он может определить, произведена или нет соответствующая проплата.

Запросы о базовых транзакциях IOTP Ping (смотри раздел 9.2.2) игнорируются.

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


Программа, которая поддерживает торговую роль покупателя IOTP может не делать:

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

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

Базовыми требованиями являются:

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

	- Продавцу, после отправки блока выбора TPO,
	- Кассиру, после отправки блока платежного запроса,
	- Агенту доставки, после отправки блока запроса доставки,

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

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

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

Рабочие ошибки (смотри раздел 4.2) в исходных сообщениях-запросах.

Технические ошибки (смотри раздел 4.1) – как IOTP, так и специфических для определенных платежных схем es – в исходных IOTP-сообщениях.

Технические ошибки в сообщении, содержащем сам блок информационного запроса.

Рабочие ошибки в исходных сообщениях

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

Технические ошибки в исходных сообщениях

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

Технические ошибки в блоке информационного запроса

Возврат сообщения Error. То есть, возврат блока Error, содержащего код ошибки (смотри раздел 7.21.2), который описывает природу ошибки в сообщении информационного запроса.


Сообщения информационого запроса транзакции

На Рисунок . 32 рассмотрен процесс реализации базовой транзакции информационого запроса.

1.	Первая роль решает сделать запрос о транзакции IOTP, например, нажав кнопку запроса в приложении IOTP. Это вызовет генерацию блока информационого запроса и посылку его соответствующей торговой роли.
1 a2	Информационый запрос. IotpMsg: блоки TransRef; подписи (опционный); информационого запроса
2.	Вторая торговая роль проверяет цифровую подпись (если она присутствует). Если получатель хочет среагировать, тогда торговая роль проверяет состояние транзакции, объекта запроса, используя IotpTransId в ID-компоненте блока ссылок транзакции, посылает сообщение первой торговой роли, после чего процесс останавливается
1 ? 2	Информационный отклик. IotpMsg: блоки TransRef; информационного отклика; подписи (опционный)
3.	Первая торговая роль проверяет блок информационного отклика и опционную подпись, выполняет необходимые действия и останавливается. Это может включать отображение статусной информации конечному пользователю.

Допустимые значения атрибута CompletionCode

Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode для доставки. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.

Значение	Описание
BackOrdered	Back Ordered. Товары, подлежащие доставке, ожидают длставки, но еще не доставлены. Доставка будет оформлена, когда товар будет получен. Это справедливо, если ProcessState = CompletedOk. Восстановление невозможно.
PermNotAvail	Постоянно не доступен (Permanently Not Available). Товары не доступны и не могут быть перезаказаны. Это справедливо, если ProcessState = Failed. Восстановление не возможно.
TempNotAvail	Временно не доступен. Товары временно не доступны и могут быть получены при повторном заказе. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.
ShipPending	Задержка доставки. Товары доступны и запланированы к доставке, но еще не доставлены. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.
Shipped	Товары доставлены (Goods Shipped). Товар уже доставлен. Ожидается подтверждение доставки. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.
ShippedNoConf	Доставлен – никакого подтверждения доставки (Shipped - No Delivery Confirmation). Товары были доставлены, но их доставку невозможно подтвердить. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.
ConsCancelled	Аннулировано Покупателем (Consumer Cancelled). Покупатель по какой-то причине решает аннулировать доставку. Этот код допустим только в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.
DelivCancelled	Доставка аннулирована (Delivery Cancelled). Агент доставки по какой-то причине отказался завершить процедуру доставки и аннулировал транзакцию. Этот код допустим только в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.
Confirmed	Подтверждено (Confirmed). Все товары были доставлены и получено подтверждение их доставки. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.
Unspecified	Неспецифицированная ошибка (Unspecified error). Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Атрибут StatusDesc должен прояснить причину. Восстановление невозможно.
TimedOutRcvr	Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение от другой торговой роли получено вновь.
TimedOutNoRcvr	Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно.

Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.

Значение	Описание
InMsgHardError	Серьезная ошибка во взодном сообщении (Input Message Hard Error). Тип блока запроса не может быть идентифицирован или является несовместимым. Следовательно никакой однодокументный обмен не может быть идентифицирован. Это может вызвать серьезную ошибку в транзакции.

7.16.6. Коды завершения информационного запроса транзакции
Код завершения требуется только тогда, когда атрибут ProcessState = Failed.

Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.

Значение	Описание
UnAuthReq	Неавторизованный запрос (Unauthorised Request). Получатель запроса состояния транзакции отказывается откликаться на запрос.

7.17. Компонент данных торговой роли
Компонент данных торговой роли содержит данные, которые должны быть пересланы между торговыми ролями вовлеченными в транзакцию.
Компоненты торговой роли определяют:
o организацию, которая сформировала компонент и
o организацию, которая его получила.
Они являются первыми сформированными и включенными в блок “отклик” и затем скопированных в соответствующий блок “запрос”. Например, кассиру может оказаться нужно проинформировать агента доставки о том, что платеж через кредитную карточку авторизован (but not captured). В другом примере продавцу может понадобиться предоставить кассиру некоторую специфическую информацию о Покупателе.
Его определение представлено ниже.

OriginatorElRef NMTOKEN #REQUIREDDestinationElRefs NMTOKENS #REQUIRED>
Атрибуты:

ID	Идентификатор, который однозначно определяет компонент данных торговой роли транзакции IOTP.
OrginatorElRef	Содержит ссылку элемента на компонент Organisation организации, которая создала компонент данных о торговой роли и включила его в блок отклика (напр., блок отклика предложения или платежа).
DestinationElRefs	Содержит ссылку элемента на компоненты Organisation организации, которая получила компонент данных о торговой роли в блоке запроса (напр., блоков запроса платежа или доставки).

Cодержимое:

PackagedContent

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

7.17.1. Кто получает компонент данных о торговой роли


Восстановление при неудаче или в случае частично завершенной доствки невозможно. Покупатель для получения текущего состояния транзакции должен использовать информационный запрос (смотри раздел 9.2.1).

7.16.4. Коды завершения аутентификации

Код завершения необходим только в случае, если атрибут ProcessState = Failed. Ниже следующая таблица содержит допустимые значения атрибута CompletionCode, которые можно использовать. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.

Значение	Описание
AutEeCancel	Аннулировано аутентифицируемым (Authenticatee Cancel). Организация по какой-то причине отказывается от аутентификации. Это может быть, например, потому что подпись аутентификационного запроса оказалась некорректной или аутентификатор оказался неизвестным или неприемлемым. Восстановление невозможно.
AutOrCancel	Аннулировано аутентификатором (Authenticator Cancel). Организация, запросившая аутентификацию по каким-то причинам отказывается проверять полученный аутентификационный отклик и аннулирует транзакцию. Восстановление невозможно.
NoAuthReq	Запрос аутентификации не возможен (Authentication Request Not Available). Аутентифицирующийся субъект не имеет данных, которые должны быть предоставлены. Например, забыт пароль или субъект не авторизован. Восстановление невозможно.
AuthFailed	Аутентификация не прошла (Authentication Failed). Аутентификатор проверил аутентификационный отклик, но эта проверка по какой-то причине не прошла. Например, оказался неправильным пароль. Восстановление может быть возможно аутентифицируемым путем повторной посылки отклика аутентификации с корректными данными.
TradRolesIncon	Торговые роли несоместимы (Trading Roles Inconsisten). Торговые роли, содержащиеся в атрибуте TradingRoleList компонента информационного запроса торговых ролей (смотри раздел 7.4) не согласуются с торговой ролью, которую аутентифицируемый играет в данной транзакции IOTP. Примеры несогласованности включают в себя: о запрос Кассира информации об Агенте доставки; о запрос Покупателя информации о Продавце. Восстановление может выполнить аутентификатор путем повторной посылки блока аутентификационного запроса с поправленной информацией.
Unspecified	Неспецифицированная ошибка (Unspecified error). Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Восстановление невозможно.
TimedOutRcvr	Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение от другой торговой роли получено вновь.
TimedOutNoRcvr	Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно.

7.16.5. Неопределенные коды завершения

Код завершения требуется только тогда, когда атрибут ProcessState = Failed.


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

Когда бы ни был получен компонент данных торговой роли в блоке "Отклик", идентифицировать компоненты Organisation, которые должны получить его, как идентифицированные атрибутом DestinationElRefs.

Когда бы ни был послан блок "Запрос", проверить, был ли он послан одной из организаций (адресат), идентифицированной атрибутом. Если это так, включить в блок "Запрос" следующее:

	- компонент данных о торговой роли, а также,
	- компонент Organisation, идентифицированной атрибутом OriginatorElRef.

7.18. Компонент типа информационного запроса

Компонент типа информационного запроса содержит информацию, которая указывает тип процесса, о котором получен запрос. Его определение представлено ниже.


ElRef NMTOKEN #IMPLIEDProcessReference CDATA #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент типа информационного запроса транзакции IOTP.
Type	Содержит тип информационного запроса. Допустимые значения типа запроса: o Offer. Запрос касается статуса предложения и обращен к продавцу. o Payment. Запрос касается статуса платежа и обращен к кассиру. o Delivery. Запрос касается статуса доставки и обращен к агенту доставки.
ElRef	Содержит ссылку элемента (смотри раздел 3.5) на компонент, к которому относится информационный запрос. Это: о Блок TPO, когда тип = Offer; o Компонент Payment, когда тип = Payment; o Компонент Delivery, когда тип = Delivery.
ProcessReference	Опционно содержит ссылку на процесс, о котором произведен запрос. Он должен быть установлен, если информация доступна. Для определения значений, которые он может принимать, смотри атрибут ProcessReference компонента Status (смотри раздел 7.16).

7.19. Компонент Signature (подпись)

Определения структур XML для подписей и сертификатов описаны в документе "Digital Signatures for the Internet Open Trading Protocol" Kent Davidson и Yoshiaki Kawatsura, опубликованном одновременно с этим документом - смотри [IOTPDSIG].


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

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

Компонент подпись:

содержит дайджесты одного или более блоков или компонентов в одном или нескольких IOTP-сообщениях в пределах одной транзакции IOTP и помещает результат в элемент Digest;

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

подписывает элемент Manifest, используя опционный сертификат, идентифицированный в компоненте Certificate блока Signature, помещая результат в элемент Value комполнента Signature.

Заметим, что может быть много элементов Value, которые содержат подписи элемента Manifest. Компонент Signature может иметь один из четырех типов:

Подпись отклика предложения,

Подпись отклика платежа,

Подпись отклика доставки, или

Подпись отклика аутентификации.

Для общего объяснения подписей смотри раздел 6.

7.19.1. Использование элементов подписи и атрибутов IOTP

Определения элементов и атрибутов содержится в [IOTPDSIG]. Ниже представлена дополнительная информация, которая описывает, как эти элементы и атрибуты используются в IOTP.

Элемент SIGNATURE
ID-атрибут является обязательным.

Элемент MANIFEST

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

Целью элемента Manifest является сокращение значения атрибута LocatorHREF, так как первая часть атрибутов LocatorHREF в подписи идентична.

Обычно в IOTP он будет содержать все символы атрибута LocatorHref вплоть до ("#") (смотри текст ниже).

Элементы ALGORITHM и PARAMETER
Элемент algorithm идентифицирует алгоритмы, использованные при формировании подписи. Тип алгоритма определяется значением алгоритма Type, который указывает, следует ли его использовать в качестве Digest-алгоритма, алгоритма подписи или алгоритма Key Agreement.


Следует использовать следующие алгоритмы дайджестов:

алгоритм [DOM-HASH]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:ibm:dom-hash";

алгоритм [SHA1]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:fips:sha1" и

алгоритм [MD5]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:rsa:md5".

Следует применять следующие алгоритмы подписи:

алгоритм [DSA]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:us.gov:dsa"

алгоритм [HMAC]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:ibm:hmac"

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

алгоритм [RSA]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:rsa:rsa"

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

Один алгоритм может использовать другие алгоритмы через посредство элемента Parameter, например:


A2


Элемент DIGEST

Атрибут LocatorHREF идентифицирует элемент IOTP, который подписан цифровым образом. Он состоит из:

значения ID-атрибута IotpTrans ID-компонента транзакции, за которым следует:

символ "#", за которым следует

ссылка элемента (смотри раздел 3.5) на элемент транзакции IOTP, который является субъектом дайджеста.

Прежде чем анализировать структуру атрибута LocatorHREF, он должен быть объединен со значением атрибута LocatorHrefBase элемента Manifest (смотри непосредственно выше).


Элемен атрибут

Должен существовать один и только один элемент атрибута, который содержит атрибут Type со значением типа подписи и содержимым равным одному из: OfferResponse, PaymentResponse, DeliveryResponse, AuthenticationRequest, AuthenticationResponse, PingRequest или PingResponse; в зависимости от типа подписи.

Значения содержимого элемента атрибута управляются процедурой, определенной в разделе 12 (IANA), и допускающей определение значений пользователем.

Атрибут Critical должен быть установлен равным true.

Элемент ORIGINATORINFO

Атрибут OriginatorRef элемента OriginatorInfo должен всегда присутствовать и содержать ссылку элемента (смотри раздел 3.5) на компонент Organisation организации, которая сформировала компонент Signature.

Элемент RECIPIENTINFO

Атрибут RecipientRefs содержит список ссылок (смотри раздел 3.5), указывающих на организации, которые должны будут проверить подлинность подписи.

7.19.2. Компонент подписи отклика предложения

Элемент Manifest подписи, который имеет тип OfferResponse должен содержать элементы дайджеста для следующих компонентов:

Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, которое содержит подпись отклика предложения;

Блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, которое содержит подпись отклика предложения

из блока TPO:

	компонент опций протокола;
	каждый из компонентов Organisation;
	каждый из компонентов списка видов платежа;

опционно, все компоненты выбора вида платежа, если они посланы Продавцу в блоке выбора TPO;

из блока отклика предложения:

	компонент Order;
	каждый из компонентов Payment;
	компонент Delivery;
	каждый из компонентов запроса аутентификации;
	любой компонент данных о торговой роли.

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

если продавец получил блок выбора TPO, содержащий компоненты выбора вида платежа, тогда генерируется элемент дайджеста для кассира, идентифицированного компонентом выбора вида платежа, и для агента доставки, идентифицированного компонентом Delivery.


Смотри раздел 6.3.1.

если Продавец не ожидает получить блок выбора TPO, тогда ренерируется элемент дайджеста для Агента доставки и всех Кассиров, вовлеченных в сделку.

7.19.3. Компонент подписи платежной расписки

Элемент Manifest компонента подписи платежной расписки должен содержать элеиенты Digest для следующих компонентов:

Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, который содержит подпись платежной расписки;

Блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, который содержит подпись платежной расписки;

компонент подписи отклика предложения;

компонент платежной расписки;

компонент Payment Note;

компонент Status;

компонент выбора вида платежа;

любой компонент данных о торговой роли.

7.19.4. Компонент подписи отклика доставки

Элемент Manifest компонента отклика доставки должен содержать элементы Digest для следующих компоентов:

Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, который содержит подпись отклика доставки;

блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, который содержит подпись отклика доставки;

компонент данных доставки покупателя, содержащихся в предыдущем запросе доставки (если имется);

компоненты Signature, содержащиеся в предыдущем запросе доставки (если имется);

компонент Status;

компонент Delivery Note.

7.19.5. Компонент подписи запроса аутентификации

Элемент Manifest компонента подписи запроса аутентификации должен содержать элементы Digest для следующих компонентов:

блок ссылки транзакции (смотри раздел 3.3) для сообщения IOTP, который содержит информацию, которая описывает сообщение и транзакцию IOTP;

Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;

следующие компоненты блока TPO:

	- компонент опций протоколов;
	- компонент Organisation.

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

	- компоненты запроса аутентификации (если имеются)
	- компонент запроса информации о торговой роли (если имеется)

7.19.6.


Компонент подписи отклика аутентификации

Элемент Manifest компонента подписи отклика аутентификации должен содержать элементы Digest для следующих компонентов:

блок ссылки транзакции (смотри раздел 3.3) для сообщения IOTP, который содержит информацию, описывающую сообщение и транзакцию IOTP;

Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;

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

	- компонент запроса аутентификации, который был использован в аутентификации (если имеется);
	- компонент информационного запроса о торговой роли (если имеются).

компоненты Organisation, содержащиеся в блоке отклика аутентификации.

7.19.7. Компонент подписи информационного запроса

Если информационный запрос подписан (смотри раздел 9.2.1) элемент Manifest компонента подписи информационного запроса должен содержать элементы Digest компонента типа информационного запроса и, если присутствует, компонент схемы платежа.

7.19.8. Компонент подписи

Если информационный отклик подписан (смотри раздел 9.2.1) элемент Manifest компонента подписи информационного запроса должен содержать элементы Digest блока торгового отклика и компонент Status.

7.19.9. Компонент подписи запроса Ping

Если запрос Ping подписан (смотри раздел 9.2.2), элемент Manifest компонента подписи запроса Ping должен содержать элементы Digest для всех компонентов Organisation.

7.19.10. Компонент подписи отклика Ping

Если отклик Ping подписан (смотри раздел 9.2.2), элемент Manifest компонента подписи запроса Ping должен содержать элементы Digest для всех компонентов Organisation.

7.20. Компонент Certificate

Определения структур XML для подписей и сертификатов описаны в работе "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Смотри также начало раздела 7.19.

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


Структура сертификата определена в [IOTPDSIG].

7.20.1. Использование в IOTP атрибутов и элементов подписи

Подробные определения упомянутых выше элементов и атрибутов содержатся в [IOTPDSIG]. Далее представлена дополнительная информация, которая описывает, как эти элементы и атрибуты используются в IOTP.

Компонент CERTIFICATE
ID-атрибут является обязательным.

Элемент VALUE
ID-атрибут является обязательным.

7.21. Компонент Error

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

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

сообщение, уведомляющее об ошибке. Сообщение IOTP, которое содержит компонент Error, который описывает ошибку, обнаруженную в сообщении.

Определение компонента Error представлено ниже.


xml:lang NMTOKEN #REQUIREDErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED Severity (Warning|TransientError|HardError) #REQUIRED

MinRetrySecs CDATA #IMPLIED

SwVendorErrorRef CDATA #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент Error транзакции IOTP.
xml:lang	Определяет язык, используемый атрибутами или дочерними элементами компонента, если только значение не переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.
ErrorCode	Содержит код ошибки, который указывает на природу ошибки в сообщении. Допустимые значения ErrorCode приведены в секции 7.21.2.
ErrorDesc	Содержит текстовое описание ошибки на языке, заданном xml:lang. Содержимое этого атрибута определено поставщиком/разработчиком программного обеспечения, которое сгенерировало компонент Error.
Severity	Определяет степень (severity) ошибки. Допустимы следующие значения: о Warning. Индицирует, что хотя имеется ошибочное сообщение, транзакция может продолжаться. о TransientError. Индицирует, что ошибка в сообщении может быть исправлена, если ошибочное сообщение, на которое указывает элемент ErrorLocation, послать повторно. o HardError. Индицирует, что в сообщении имеется неустранимая ошибка, трпнзакция IOTP должна быть остановлена.
MinRetrySecs	Этот атрибут должен присутствовать, если Severity равен TransientError. Он равен минимальному числу полных секунд, которое приложение IOTP, получившее сообщение об ошибке, должно подождать прежде чем переадресовать сообщение, идентифицированное элементом ErrorLocation.

Если атрибут Severity не равен TransientError, тогда значение этого атрибута игнорируется.

SwVendorErrorRef

Этот атрибут является ссылкой, чье значение установлено поставщиком/разработчиком программы, которая сформировала компонент Error. Он должен содержать данные, которые позволяют поставщику идентифицировать точную позицию в его прогрпмме и установить причины, которые вызвали сообщение об ошибке. Смотри также атрибут SoftwareID Id-элемента сообщения в блоке ссылки транзакции (раздел 3.3).

Cодержимое:

ErrorLocation

Идентифицирует Id транзакции IOTP сообщения с ошибкой и, если возможно, элемент и атрибут сообщения, который вызвал формирование компонента Error.

Если Severity ошибки не равно TransientError, может быть, если требуется, специфицировано более одного ErrorLocation, в зависимости от природы ошибки (смотри раздел 7.21.2) и от конкретной реализации программы.

PackagedContent

Содержит дополнительные данные, которые могут использоваться для понимания ошибки. Его содержимое может варьироваться в зависимости от природы ошибки (смотри раздел 7.21.2) и ои поставщика/разработчика приложения IOTP. Определение f PackagedContent смотри в разделе 3.7.

7.21.1. Общие принципы обработки ошибок

Если об ошибке уведомляют более чем один компонент Error в сообщении, следует выполнять обработку компонента Error с наивысшим значением атрибута severity. В этом контексте, HardError имеет выше уровень “серьезности” (severity), чем TransientError, который имеет серьезность выше, чем Warning.

7.21.1.1. Severity = предупреждение

Если приложение генерирует сообщение об ошибке с компонентом Error, где атрибут Severity = Warning, тогда, если сообщение об ошибке не содержит другого компонента ошибки с атрибутом Severity выше, чем Warning, сообщение должно включать торговые блоки и компоненты, которые следовало бы включить, если бы сообщения об ошибке отсутствовало. Если сообщение получено с компонентом Error, где Severity = Warning, тогда:

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

разработчик приложения IOTP должен:

	- продолжеть транзакцию как обычно или
	- прервать транзакцию, выработав сообщение с компонентом Error и атрибутом Severity = HardError (смотри раздел 7.21.1.3).

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


Если они не сформированы, то вырабатывается сообщение с компонентом Error и Severity = HardError.

7.21.1.2. Severity = переходная ошибка

Если приложение генерирует сообщение с компонентом Error, где атрибут Severity = TransientError, тогда в сообщение должен быть только один компонент Error. Кроме того, должен присутствовать атрибут MinRetrySecs. Если сообщение, уведомляющее об ошибке получено с компонентом Error, где Severity = TransientError тогда:

если атрибут MinRetrySecs присутствует и имеет правильное значение, тогда следует использовать данную величину MinRetrySecs. В противном случае, если MinRetrySecs отсутствует или имеет неверное значение, тогда:

	- сформироать сообщение с компонентом Error и атрибутом Severity = Warning, после чего послать его со следующим сообщением (если такое имеется) торговой роли, которая прислала сообщение об ошибке с неверным значением MinRetrySecs и
	- использовать величину MinRetrySecs, установленное поставщиком/ разработчиком приложения IOTP.

Проверить, что только один элемент ErrorLocation содержится в компоненте Error и что он относится к сообщению, которое было послано получателем компонента Error с Severity = TransientError. Если имеется более одного элемента ErrorLocation, тогда генерируется сообщение со степенью серьезности равным HardError.

7.21.1.3. Severity = Hard Error

Если приложение генерирует сообщение об ошибке с компонентом Error, где атрибут Severity = HardError, тогда в сообщении должен быть только один компонент Error.

Если получено сообщение с компонентом Error, где атрибут Severity = HardError, транзакция прерывается.

7.21.2. Коды ошибок

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

Значение	Описание
Reserved	Reserved. Эта ошибка зарезервирована поставщиком/ разработчиком программы. Контактируйте, если требуется, с поставщиком/разработчиком программы. Смотри ID-атрибут Software Id-элемента сообщения в блоке ссылок транзакции (раздел 3.3).
XmlNotWellFrmd	XML плохо сформирован. Документ XML плохо сформатирован. Смотри [XML]Ю, для того чтобы понять, что значит "хорошо сформатирован". Даже если XML сформатирован плохо, он должен быть просмотрен, найден блок ссылок транзакции, с тем чтобы было можно правильно сформировать отклик Error.
XmlNotValid	XML некорректен. Документ XML сформатирован хорошо, но он некорректен. Для того чтобы понять, что значит "корректен" смотри [XML], в частности: oдокумент XML не следует регламентациям, определенным декларацией типов документов IOTP (DTD) (смотри раздел 13) и o документ XML не следует регламентациям, определенным расширениям декларации типов документов [XML Namespace].

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

ElUnexpected	Нестандартный элемент. Несмотря на то что документ XML сформирован правильно и корректен, присутствует элемент, который не является стандартным для данного контекста согласно правил и ограничениям, содержащимся в данной спецификации.
ElNotSupp	Элемент не поддерживается. Несмотря на то что документ XML сформирован правильно и корректен, присутствует элемент, который: o согласуется с правилами и ограничениями данной спецификации, но o не поддерживается приложением IOTP, которое обрабатывает IOTP-сообщение.
ElMissing	Элемент отстутствует. Несмотря на то что документ XML сформирован правильно и корректен, отсутствует элемент, который должен присутствовать, если следовать правилам и ограничениям данной спецификации.

В этом случае следует установить PackagedContent компонента Error соответствующим типу пропущенного элемента.

ElContIllegal	Содержимое элемента не верно. Несмотря на то что документ XML сформирован правильно и корректен, элемент Content содержит значения, которые не согласуются с правилами и ограничениями данной спецификации.
EncapProtErr	Ошибка инкапсулированного протокола. Несмотря на то что документ XML сформирован правильно и корректен, PackagedContent элемента содержит данные инкапсулированного протокола, которые неверны.
AttUnexpected	Нестандартный атрибут. Несмотря на то что документ XML сформирован правильно и корректен, присутствие такого атрибута в данном контексте не предусмотрено и не согласуются с правилами и ограничениями данной спецификации.
AttNotSupp	Атрибут не поддерживается. Несмотря на то что документ XML сформирован правильно и корректен, и приутствие атрибута элемента согласуется с правилами и ограничениями данной спецификации, он не поддерживается конкретной программной реализацией, которая обрабатывает сообщение IOTP.
AttMissing	Атрибут отсутствует. Несмотря на то что документ сформирован правильно и корректен, отсутствует атрибут, который согласно правилам и ограничениям данной спецификации должен присутствовать.

В этом случае следует установить PackagedContent компонента Error соответствующим типу пропущенного атрибута.

AttValIllegal	Не верно значение атрибута. Атрибут содержит значение, которое не согласуется с правилами и ограничениями данной спецификации.
AttValNotRecog	Значение атрибута не распознано. Атрибут содержит значение, которое приложение IOTP, обрабатывающее сообщение, не смогло распознать.
MsgTooLarge	Сообщение имеет слишком больую длину. Сообщение слишком велико для приложения, его обрабатывающего.
ElTooLarge	Элемент слишком велик. Элемент слишком велик для приложения, его обрабатывающего.
ValueTooSmall	Значение слишком мало. Значение всего или части элемента Content или атрибута, хотя и верно, но слишком мало.
ValueTooLarge	Значение слишком велико. Значение всего или части элемента Content или атрибута, хотя и верно, но слишком велико.
ElInconsistent	Элемент не согласован. Несмотря на то что документ сформирован правильно и корректен, согласно правилам и ограничениям данной спецификации: о содержимое элемента не согласуется с содержимым других элементовили их атрибутов или о значение атрибута не согласуется со значением одного или нескольких других атрибутов.

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

TransportError	Транспортная ошибка (Transport Error). Этот код ошибки используется для индикации проблем с транспортным механизмом, которые приводят к потере сообщения. Она обычно ассоциируется с переходной ошибкой. Объяснение переходной ошибки содержится с атрибуте ErrorDesc. Значения, которые могут использоваться в ErrorDesc с TransportError специфицированы в приложении IOTP для транспортного механизма.
MsgBeingProc	Сообщение обрабатывается (Message Being Processed). Этот код ошибки используется только с серьезностью (Severity) переходных ошибок. Код указывает, что предыдущее сообщение обрабатывается и, если в орговоренное время, заданное атрибутом MinRetrySecs, не получено отклика, оригинальное сообщение следует послать вновь.
SystemBusy	Система занята (System Busy). Этот код ошибки используется только с серьезностью (Severity) переходных ошибок. Он указывает, что сервер, который получил сообщение, в настоящее время занят и обработать сообщение не может. Если в орговоренное время, заданное атрибутом MinRetrySecs, не получено отклика, оригинальное сообщение следует послать вновь.

Если транспортный механизм сервера/системы (например, HTTP) занят, следует использовать транспортные ошибки. Этот код нужно использовать в связи с серверами/системами IOTP или другими аналогичными системами, с которыми связан IOTP.

UnknownError

Неизвестная ошибка. Индицирует, что транзакция не может завершиться по неидентифицированной причине. Атрибут ErrorDesc следует использовать для индикации природы проблемы. Эта ошибка может быть применена для указания, например, внутренней ошибки оконечного сервера или процесса клиента.

7.21.3. Элемент положения ошибки

Элемент Error Location указывает элемент и опционно атрибут в сообщении, с которым ассоциируется ошибка. Он содержит ссылку на сообщение IOTP, торговый блок, торговый компонент, элемент и атрибут, где обнаружена ошибка.

	NMTOKEN #REQUIRED
IotpMsgRef NMTOKEN #IMPLIED	BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED	ElementRef NMTOKEN #IMPLIED

AttName NMTOKEN #IMPLIED>

Атрибуты:

ElementType	Имя типа элемента, где обнаружена ошибка. Например, если элемент декларирован как
IotpMsgRef	Значение ID-атрибута Id-компонента сообщения (смотри раздел 3.3.2), к которому относится компонент Error.
BlkRef	Если ошибка ассоциирована со специфическим торговым блоком, тогда это значение ID-атрибута торгового блока, где обнаружена ошибка.
CompRef	Если ошибка ассоциирована со специфическим торговым компонентом, тогда это значение ID-атрибута торгового компонента, где обнаружена ошибка.
ElementRef	Если ошибка ассоциирована со специфическим элементом торгового компонента, тогда, если элемент имеет атрибут с типом (смотри [XML]) "ID", тогда это значение данного атрибута.
AttName	Если ошибка ассоциирована со значением атрибута, тогда это имя данного атрибута. В этом случае PackagedContent компонента Error должен содержать значение атрибута.

Заметим, что следует включать как можно больше атрибутов.Например, если атрибут в дочернем элементе торгового компонента содержит неверное значение, тогда должны присутствовать все атрибуты ErrorLocation.

Функциональная схема операция IOTP

Рисунок .7. Функциональная схема операция IOTP

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

Покупка. Поддерживает предложение, платеж и, опционно, доставку.

Возврат. Поддерживает возврат денег для сделанной ранее покупки.

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

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

Отзыв. Поддерживает отзыв электронного платежа из финансовой организации.

Депозит. Поддерживает депозит электронного платежа в финансовой организации.

Запрос. Поддерживает запрос состояния транзакции IOTP, которая в данный момент реализуется или уже завершилась.

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

3.2. Сообщение IOTP
Как было описано выше, сообщения IOTP представляют собой [XML] документы, которыми обмениваются торговые роли, участвующие в сделке.
XML-определение сообщения IOTP выглядит следующим образом.
( TransRefBlk,

	SigBlk?,
	ErrorBlk?,
	( AuthReqBlk |
	AuthRespBlk |
	AuthStatusBlk |
	CancelBlk |
	DeliveryReqBlk |
	DeliveryRespBlk |
	InquiryReqBlk |
	InquiryRespBlk |
	OfferRespBlk |
	PayExchBlk |
	PayReqBlk |
	PayRespBlk |
	PingReqBlk |
	PingRespBlk |
	TpoBlk |
	TpoSelectionBlk
	)*

) >
xmlns CDATA
'iotp:ietf.org/iotp-v1.0'
Содержимое:
TransRefBlkсодержит информацию, которая характеризует сообщение IOTP в пределах операции IOTP (смотри раздел 3.3)

AuthReqBlk, AuthRespBlk,	Торговые блоки.
DeliveryReqBlk	Торговые блоки присутствуют в сообщениях IOTP, а само содержимое
DeliveryRespBlk	торгового блока зависит от типа выполняемой операции IOTP
ErrorBlk	смотри определение каждой операции в разделе 9.
InquiryReqBlk,
InquiryRespBlk,
OfferRespBlk, PayExchBlk,
PayReqBlk	Полные определения каждого торгового блока описаны в разделе 8.
PayRespBlk, PingReqBlk, PingRespBlk, SigBlk, TpoBlk, TpoSelectionBlk

Атрибуты:

Xmlns

Определение [XML Namespace] для сообщений IOTP.

3.2.1. XML Document Prolog

Сообщение IOTP является корневым элементом XML-документа. Оно, следовательно, должно предшествоваться соответствующим прологом документа XML. Например:




...
3.3. Блок ссылок операции (Transaction Reference Block)

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

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

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

Нуль или более компонентов Related To, которые связывают эту операцию IOTP с другими операциями или другими событиями, используя идентификаторы этих событий.

Определение блока ссылок операции (Transaction Reference Block) выглядит следующим образом:




Атрибуты:

ID	Идентификатор, который однозначно определяет блок ссылок операции в пределах IOTP-процедуры (смотри раздел 3.4).

Cодержимое:

TransId	Смотри 3.3.1 Id-компонент операции.
MsgId	Смотри 3.3.2 Id-компонент сообщения.
RelatedTo	Смотри 3.3.3 Компонент Related To.

3.3.1.


Идентификационная компонента транзакции

Идентификационная компонента транзакции содержит информацию, которая однозначно задает транзакцию IOTP. Ее определение представлено ниже:

	ID #REQUIRED
Version	NMTOKEN #FIXED '1.0'
IotpTransId	CDATA #REQUIRED
IotpTransType	CDATA #REQUIRED
TransTimeStamp	CDATA #REQUIRED >

Атрибуты:

ID	Идентификатор, который однозначно определяет Id-компонент транзакции в рамках операции IOTP.
Version	Определяет версию IOTP и, следовательно структуру сообщений IOTP, которые используются транзакцией IOTP.
IotpTransId	Содержит данные, которые однозначно определяют транзакцию IOTP. Это атрибут должен отвечать правилам для идентификаторов сообщений [RFC 822].
IotpTransTyp	Это тип исполняемой транзакции IOTP. Для базовой версии IOTP он идентифицирует "стандартную" транзакцию IOTP и предполагает определенную последовательность и содержимое сообщений IOTP, которыми обмениваются торговые роли. Корректными значениями атрибута являются:
о	BaselineAuthentication (Базовая аутентификация)
o	BaselineDeposit
o	BaselinePurchase
o	BaselineRefund
o	BaselineWithdrawal
o	BaselineValueExchange
o	BaselineInquiry
o	BaselinePing

Значение IotpTransType управляется процедурой, описанной в разделе 12 IANA Considerations, которая позволяет пользователю определить величины IotpTransType. В последних версиях IOTP, этот список будет расширен с целью поддержки различных типов транзакций IOTP. Вероятно, будет поддержан динамический тип (Dynamic), который указывает, что последовательность шагов в транзакции не является стандартной.

TransTimeStamp

Там где система, запускающая транзакцию IOTP, имеет внутренние часы, атрибут устанавливается равным времени старта транзакции IOTP в формате [UTC].

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

Некоторые системы не могут генерировать временные метки.


В этом случае этот атрибут должен содержать значение "NA" (Not Available).

3.3.2. Идентификатор сообщения

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

	RespIotpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED	LangPrefList NMTOKENS #IMPLIED
CharSetPrefList NMTOKENS #IMPLIED	SenderTradingRoleRef NMTOKEN #IMPLIED
SoftwareId CDATA #REQUIRED	TimeStamp CDATA #IMPLIED >

Атрибуты:

ID	Идентификатор, который однозначно идентифицирует сообщение IOTP в рамках транзакции IOTP (смотри раздел 3.4 ID атрибуты). Заметим, что если сообщение IOTP пересылается повторно, тогда значение этого атрибута остается неизменным.
RespIotpMsg	Это ID-атрибут содержит Id-компонент сообщения IOTP, откликом на которое оно является. Таким образом все сообщения IOTP в пределах транзакции оказываются связаны. Это поле необходимо каждому сообщению IOTP за исключением первого сообщения IOTP в транзакции.
SenderTradingRoleRef	Элемент ссылки (смотри раздел 3.5) торговой роли, которая сформировала сообщение IOTP. Он используется, чтобы идентифицировать сетевую позицию (Net Locations) (смотри раздел 3.9) торговой роли, которой требуется сообщить о технических ошибках (смотри раздел 4.1), связанных с торговыми блоками.
Xml:lang	Определяет язык, используемый атрибутом, или дочерние элементы в пределах этого компонента, если не переписан атрибутом xml:lang в дочернем элементе. Смотри раздел 3.8.
LangPrefList	Опционный список языковых кодов, который согласуется с идентификацией языков [XML]. Он используется отправителем, чтобы указать порядок предпочтения языков, которые получатель сообщения должен использовать при подготовке отклика. Получатель не обязан использовать один из указанных языков.
CharSetPrefList	Опционный список идентификаторов символьных наборов, которые соответствуют символам в [XML]. Он используется отправителем для указания порядока предпочтения символьных наборов, которые получатель может применить при формировании отклика. Получатель не обязан использовать один из указанных символьных наборов.
SoftwareId	Содержит информацию, которая идентифицирует программу, сформировавшую сообщение IOTP. Его целью является помочь разрешить проблему совместной работы различных программ, обменивающихся сообщениями. Это простая текстовая строка на языке, определенном xml:lang. Она должна содержать, по крайней мере:
	имя производителя программного продукта название программного продукта версию программы форму программного обеспечения (build)
TimeStamp	Когда прибор, отправляющий сообщение имеет внутренние часы, атрибут делается равным времени генерации сообщения IOTP в формате [UTC].

3.3.3. Компонент Related To

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

	xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED	Relation CDATA #REQUIRED

RelnKeyWords NMTOKENS #IMPLIED >
Атрибуты:

ID	Идентификатор, который однозначно jghtltkztn компонент Related To в рамках транзакции IOTP.
xml:lang	Определяет язык, использованный атрибутом или дочерним элементом в данном компоненте, если не переписан атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.
RelationshipType	Определяет тип отношения. Корректными значениями являются:

IotpTransaction, в случае которого элемент Packaged Content содержит IotpTransId другой транзакции IOTP.

Ссылка, в случае которой элемент Packaged Content содержит указатель на некоторый другой, не-IOTP документ.

Значения RelationshipType управляются процедурами, определенными в разделе 12 IANA Considerations, которые позволяют пользователю определить свои значения атрибута.

Relation

Атрибут Relation содержит фразу на языке, определенном xml:lang, он определяет природу отношений между транзакцией, которая содержит этот компонент и другой транзакцией или другим событием. Окончательное текстовое выражение оставлено на усмотрение составителей программ IOTP.

Целью атрибута является обеспечение торговых ролей, включенных в транзакцию IOTP, объяснением природы отношений между транзакциями. Следует позаботиться о том, чтобы слова, использованные в атрибуте Relation, правильно указывали "направление" отношений. Например: одна транзакция может быть возвратом денег для другой выполненной ранее транзакции. В этом случае транзакция, которая возвращает деньги, должна содержать слова атрибута Relation, такие как "возврат за", а не "возврат кому" или просто "возврат".

RelnKeyWords

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

Cодержимое:

PackagedContent

Packaged Content (смотри раздел 3.7) содержит данные, которые идентифицируют связанные транзакции. Его формат варьируется в зависимости от значения атрибута RelationshipType.

3.4. ID-атрибуты

IOTP-сообщения, блоки (т.e. блоки ссылок операции и торговые блоки), торговые компоненты (включая ID-компонент транзакции и компонент подписи) и некоторые их дочерние элементы задаются атрибутом "ID" XML, который служит для идентификации этих XML-элементов. Эти элементы используются так, что один элемент может ссылаться на другой. Всем этим атрибутам присваиваются ID.

Значения каждого ID-атрибута является уникальным в пределах транзакции IOTP т.e. набор IOTP-сообщений, который имеет тот же самый компонент ID транзакции. Однажды присвоенное значение ID-атрибута элемента никогда не меняется. Это означает, что когда элемент копируется, значение ID-атрибута остается неизменным.

Как следствие можно использовать эти идентификаторы для ссылки и нахождения содержимого любого сообщения IOTP, блока или компонента (смотри раздел 3.5).

3.4.1. Определение ID-атрибутов сообщений IOTP

ID-атрибут Id-компонента IOTP-сообщения должен быть уникальным в пределах транзакции IOTP. Его определение представлено ниже:

IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix
IotpMsgIdPrefix ::= NameChar (NameChar)*
IotpMsgIdPrefix Кроме того сообщения, которые содержат: торговый блок информационного запроса, информационного отклика, запроса или отклика Ping, используют один и тот же префикс для всех сообщений, посланных Продавцом или Покупателем:

о	"M" - Продавец (Merchant)
о	"C" – Покупатель (Consumer)

Для сообщений, которые содержат торговый блок информационного запроса или блок запроса Ping, префикс делается равным "I" (Inquiry).


Для сообщений, которые содержат торговый блок отклика на информационный запрос или блок отклика Ping, префикс равен "Q".

Префикс для других торговых ролей в сделке содержится в компоненте Organisation (организации) и прописывается обычно Продавцом. Ниже представлены рекомендуемые значения:

о	"P" - Первый Кассир
o	"R" – Второй Кассир
o	"D" – Агент доставки
o	"C" – Доставка (Deliver To)

Префиксы должны содержать один символ. NameChar имеет то же значение, что и определение NameChar в [XML].

IotpMsgIdSuffix

Суффикс состоит из одной или более цифр. Суффикс должен быть уникальным для данной торговой роли транзакции IOTP. Рекомендации сводятся к следующему:

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

Короче Id-компонент первого сообщения IOTP, посланного Покупателем будет иметь ID-атрибут "C1", второе - "C2", третье - "C3" и т.д. Цифра имеет то же определение что и в [XML].

3.4.2. Определения ID-атрибута для блока и компонента

ID-атрибут блоков и компонентов в пределах транзакции IOTP также должен быть уникальным. Ниже представлено его определение:

BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix
IdSuffix ::= Digit (Digit)*

IotpMsgId_value

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

В IOTP, торговые компоненты и торговые блоки копируются из одного сообщения IOTP в другое. I D-атрибут не изменяется, когда существующий торговый блок или компонент копируется в другое сообщение IOTP.

IdSuffix

Суффикс состоит из одной или более цифр. Суффикс должен быть уникальным для ID-атрибута ID-компонента сообщения, используемого для генерации ID-атрибута. Рекомендуется здесь следующее:

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

Короче, первый новый блок или компонент добавляется ко второму посылаемому сообщению IOTP, например, первый ID-атрибут - "C2.1", второй - "C2.2", третий - "C2.3" и т.д.Цифра имеет то же определение, что и в [XML].

3.4.3. Пример использования ID-атрибутов

На диаграмме проиллюстрировано, как используются значения ID-атрибутов.

Интернет в Ethernet

4.1.1.3 Интернет в Ethernet

В Интернет не существует иерархии сетей. Локальная сеть на основе Ethernet, две ЭВМ, связанные через последовательный интерфейс, или общенациональная сеть страны - это все сети и по логике Интернет они все равны. Каждая сеть имеет свое имя и как минимум один IP-адрес. Имя привычнее для людей, адреса - для машин. Между именами и адресами существует строгое соответствие.
Для того чтобы пояснить взаимодействие различных систем в сети, рассмотрим сильно упрощенную схему обработки команды telnet vxdesy.desy.de, которая предполагает осуществление удаленного доступа к vx-кластеру в ДЕЗИ, Гамбург (вызов через windows обрабатывается практически аналогично). Сначала ЭВМ выделяет команду telnet и запускает соответствующую программу. Эта программа рассматривает символьный адрес vxdesy.desy.de в качестве параметра команды telnet.

Интернет

4.4 Интернет

Номер раздела	Название раздела	Объем в страницах	Объем в кбайт
4.4		3	2
4.4.1		10	91
4.4.2		7	5
4.4.3		15	135
4.4.4		10	93
4.4.5		10	103
4.4.6		4	141
4.4.7		1	11
4.4.8		1	13
4.4.9		3	20
4.4.10		3	30
4.4.11		10	86
4.4.12		15	100
4.4.13		6	52
4.4.14		5	39
4.4.15		47	190
4.4.16		11	68

Виртуальная сеть виртуальных сетей - Интернет является самой большой и самой популярной сетью. Можно смело утверждать, что эта сеть сохранит это лидерство в ближайшие годы. Привлекательность сети не только в том, что это единая среда общения людей, находящихся в разных странах и на разных континентах. Интернет предоставляет все более широкий спектр услуг. Это и информационно-поисковые системы, телефония, аудио и видео письма, доставляемые за считанные секунды в любую точку мира (где имеется Интернет), видеоконференции, электронные журналы, службы новостей, дистанционное обучение, банковские операции и многое, многое другое. Интернету предстоит мучительная процедура перехода на 128-битовые адреса (IPv6), но по ее завершении можно ожидать дальнейшего расширения списка услуг. Уже сегодня Интернет стал средой, предоставляющей возможность целевой рекламы и дистанционной торговли. Уже в начале следующего века сети станут самым мощным средством массовой информации. Но для решения всех этих проблем в этой сфере еще очень много надо сделать. Современные поисковые системы, несмотря на впечатляющие успехи, требуют существенного улучшения эффективности, много надо сделать для того, чтобы Интернет пришел в каждую квартиру.
Сегодня Интернет использует многие десятки протоколов. Если сюда добавить протоколы физического уровня, то их число превысит сотню. На уровне локальных сетей наиболее распространены различные разновидности Ethernet, а также Token Ring и некоторые другие. Особенно велико разнообразие протоколов межсетевого обмена. Здесь помимо PPP используется FDDI, X.25, ISDN, ATM, SDH, Fibre Channel и пр..
На транспортном уровне в Интернет работают протоколы UDP (без установления соединения) и TCP (с установлением соединения). Это два принципиально разных подхода к передаче данных. В обоих случаях и передатчик и приемник имеют индивидуальные IP-адреса и порты. Но в случае TCP они ассоциируются в соединители (socket) - две пары IP-адрес-порт и прием/передача в рамках одной сессии происходит по схеме точка-точка. Для UDP же допускается возможность передачи одновременно нескольким приемникам (мультикастинг) и прием данных от нескольких передатчиков в рамках одной и той же сессии. Протокол TCP используется для поточной передачи данных, при которой доставка гарантируется на протокольном уровне. Это обеспечивается обязательным подтверждением получения каждого пакета TCP. Напротив, протокол UDP не требует подтверждения получения. В этом случае, как правило, исключается также и фрагментация пакетов, так как пакеты при схеме без установления соединения никак не связаны между собой. По этим причинам UDP в основном служит для передачи мультимедийных данных, где важнее своевременность, а не надежность доставки. Протокол TCP используется там, где важна надежная, безошибочная доставка информации (файловый обмен, передача почтовых сообщений и WEB-технология).

Схема без установления соединения привлекательна также тем, что позволяет при передаче данных от исходного источника к большому числу приемников минимизировать общий трафик. Если бы для этой цели использовался протокол TCP, то при N приемниках надо было бы сформировать N виртуальных каналов и транспортировать N идентичных пакетов (Рисунок 4.4.1). В случае UDP от передатчика до точки разветвления передается только один пакет, что уменьшает загрузку данного участка в N раз (Рисунок 4.4.2). Причем аналогичная экономия может быть реализована и по пути к очередной точке разветвления (смотри описание протокола мультикастинг-маршрутизации PIM).

Локальная часть IP-адреса

Рисунок 4.1.1.3.3. Локальная часть IP-адреса

Такая схема обеспечивает необходимую гибкость, дает возможность разделить локальную сеть на субсети. При работе с субсетью необходимо использовать 32-разрядную маску. Разряды маски должны равняться 1, если сеть рассматривает данный бит как часть адреса сети, и 0, если он характеризует адрес ЭВМ в этой сети. Например: 255.255.255.254 (десятично-точечное представление)
11111111 11111111 11111111 11111110 (двоичное представление)
описывает маску субсети, в которой работает автор. Некоторую информацию о масках в работающей сети можно получить с помощью команды ifconfig (SUN):
/usr/etc/ifconfig -a (курсивом здесь и далее выделяются команды, введенные с клавиатуры)
le0: flags=863
inet 193.124.224.35 netmask ffffffe0 broadcast 193.124.224.32
lo0: flags=869
inet 127.0.0.1 netmask ffffff00,
где le0 и lo0 - имена интерфейсов, флаг -a предполагает выдачу данных обо всех интерфейсах.
Во всех схемах IP-адресации адрес со всеми единицами в секции адрес ЭВМ (host) означает широковещательное обращение ко всем ЭВМ сети. Следует помнить, что широковещательные запросы сильно перегружают сеть, и без особой необходимости их использовать не следует. В настоящее время обсуждаются четыре предложения усовершенствования IP-адресации (см. RFC-1454):
IP-адрес безусловно удобный для использования ЭВМ, почему-то плохо запоминается людьми, поэтому они разработали символьную систему имен для узлов Интернет. Эта система (DNS- ) имеет иерархический характер. Имя содержит несколько полей, разделенных символом "." (точка). В качестве примера можно привести имя домена itepnet - cl.itep.ru. Это имя содержит три поля. Поле ru указывает на принадлежность данного домена России, поле itep определяет принадлежность узла ITEP (Institute for Theoretical and Experimental Physics), cl - характеризует то, что данное конкретное имя относится к кластеру ЭВМ (имя субдомена). Никаких ограничений на число полей в имени, кроме налагаемых здравым смыслом, не существует. Собственно имя домена - это itep.ru. Самое правое поле в имени домена характеризует принадлежность к определенному типу организации или стране.

На показана зависимость числа атак от времени суток, полученная за дней

Рисунок 2. На Рисунок 3 показана зависимость числа атак от времени суток, полученная за 19 дней.

На показано распределение атак

Рисунок 3. На Рисунок 4 показано распределение атак по доменным зонам. Из распределения видно, что этому занятию предаются чаще всего "жители" больших и комерческих сетей. Хотя нельзя исключить, что именно они являются чаще жертвами хакеров.

Рисунок 4.

Код атаки	Описание атаки
2000001	Land attack. Атакер пытается замедлить работу вашей машины, послав пакет с идентичными адресами получателя и отправителя. Для стека протоколов Интернет такая ситуация не нормальна. ЭВМ пытается выйти из бесконечной петли обращений к самой себе. Имеются пэтчи для большинства операционных систем.
2000002	Unknown IP protocol. Традиционными транспортными протоколами являются UDP, TCP и ICMP, которые работают поверх протокола IP. Код протокола определяется полем тип протокола заголовка IP-дейтограммы. Существует большое число протоколов, которые идентифицируются с помощью номеров портов, например, HTTP, использующий в качестве транспорта TCP. Появление незнакомого протокола должно всегда настораживать, так как может нарушить нормальную работу программ.
2000003	Teardrop attack. Опасное перекрытие IP-фрагментов, сформированное программой teardrop. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем. Адрес отправителя вероятнее всего не является истинным. Это означает, что отправитель использует фальшивый IP-адрес, и прикидывается кем-то еще. К сожалению, не существует простых способов определить, кто в действительности посылает кадры с искаженным адресом отправителя.
2000004	NewTear attack. Опасное перекрытие IP-фрагментов, сформированное программой newtear. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем. Адрес отправителя вероятнее всего не является истинным.
2000005	SynDrop attack. Опасное перекрытие IP-фрагментов, сформированное программой syndrop. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем.
2000006	TearDrop2 attack. Тоже что и, например, SynDrop, но для программы teardrop2
2000007	Bonk DoS..
2000008	Boink DoS. Тоже что и, например, SynDrop, но для программы boink
2000009	IP Fragment overlap. Смотри, например 2000005
2000010	IP last fragment length changed..
2000011	Too much IP fragmentation..
2000012	Ping of death. Предпринимается попытка послать пакет, длина которого больше теоретического предела 65536 байтов. Системы до 1997 года были уязвимы для такой атаки. Это делалось, например с помощью ping -l 65550. 2000013 IP source route. Попытка вторжения с использованием IP-опции "маршрут отправителя". В настоящее время эта опция заблокирована большинством маршрутизаторов. 2000014 Zero length IP option. Некоторые системы при этом повисают 2000015 Nestea attack. Опасное перекрытие IP-фрагментов, сформированное программой nestea. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем. Адрес отправителя вероятнее всего не является истинным. Это означает, что отправитель использует фальшивый IP-адрес, и прикидывается кем-то еще. К сожалению, не существует простых способов определить, кто в действительности посылает кадры с искаженным адресом отправителя. 2000016 Empty fragment. Когда пакеты слишком длины, они могут быть фрагментированы. Система контроля фиксирует фрагмент с нулевой длиной. Например, IP-заголовок имеет 20-байт, а данных вообще нет. Это может указывать, что: Атакер пытается обойти систему контроля вторжения. Некоторое сетевое оборудование (маршрутизаторы/переключатели) работают некорректно, генерируя такие фрагменты. Имеется ошибка в стеке TCP/IP машины, посылающей пакет. Атакер пытается предпринять DoS-атаку против вашей системы. Ядра Linux для версий между 2.1.89 и 2.2.3 были уязвимы для атак DoS с привлечением этой методики. Каждый такой фрагмент вызывает некоторую потерю памяти. Повторно посылая такие фрагменты, можно вызвать кризис из-за отсутствия свободной памяти. Ceotcndetn cкрипт с именем sesquipedalian, который был написан для использования этой ошибки. 2000017 IP unaligned timestamp. 2000018 Jolt2. 2000019 Jolt. 2000020 IP microfragment. Некоторые программы рушатся при получении временной метки, не выровненной по границе, кратной 32 бит. 2000021 SSping attack. Попытка атаки с помощью некорректного формата фрагментов. 2000022 Flushot attack. 2000023 IP source route end. 2000024 Oshare attack. 2000025 IP fragment data changed. 2000101 Traceroute. Кто-то пытается отследить путь от своей машины к вашей. Утилита traceroute широко используется в Интернет для поиска пути между машинами. Программа traceroute выполняет эту работу и определяет виртуальный путь через Internet. Программа traceroute не является опасной. Не существует способа проникнуть в вашу ЭВМ, используя ее. Однако она помогает хакеру отследить ваши соединения через Интернет. Эта информация может использоваться для компрометации некоторых других участников ваших связей. Например, в прошлом этот вид информации использовался хакерами для того, чтобы отключить свою жертву от Интернет, заставив ближайший маршрутизатор повесить телефонную линию. 2000102 Echo storm. Необычно большое число пакетов пришло за ограниченный период времени. Pings Довольно частой атакой домашних пользователей, играющих в сетевые игры или общающихся через сеть, является блокировка их канала с помощью большого числа пакетов Ping. Сейчас ведутся работы, для того чтобы позволить пользователю конфигурировать , чтобы было можно игнорировать такое вторжение. Смотри статью . 2000103 Possible Smurf attack initiated.. 2000104 ICMP unreachable storm.. 2000105 ICMP subnet mask request. Поступил извне ICMP-запрос маски. В норме этого не должно быть. Атакер исследует структуру сети. 2000106 Ping sweep. 2000107 Suspicious Router advertisement. Подозрительное анонсирование новых маршрутов. Атакер возможно пытается перенаправить трафик на себя. Для этого может использоваться, в том числе, и ICMP-протокол. Соответствующие опции должны всегда вызывать подозрение. 2000108 Corrupt IP options. Опции IP на практике почти не используются. По этой причине в их обработке имеется достаточно много ошибок. Ими часто пытаются воспользоваться хакеры. Появление в пакете IP-опций должно вызывать подозрения. 2000109 Echo reply without request. Это может быть результатом взаимодействия хакера с засланным троянским конем. Может быть это и результатом дублирования вашего IP-адреса. В любом случае такие пакеты достойны внимания. 2000110 ICMP flood.. 2000111 Twinge attack. То же, что и ICMP-flood 2000112 Loki. Атака, использующая "заднюю дверь" приложения или ОС. Это может быть сделано для сокрытия трафика, например под видом ICMP-эхо или UDP-запросов к DNS и т.д. Воспользуйтесь командой netstat, чтобы выяснить, какие raw SOCKET открыты. 2000201 UDP port scan.. 2000202 UDP port loopback. Пакет UDP путешествует между двумя эхо-портами. Такие пакеты могут делать это бесконечное число раз, используя всю имеющуюся полосу сети и производительность ЦПУ. Имеется несколько стандартных услуг такого рода, которые могут работать в системе. Среди них: echo (порт 7) дневная квота (порт 17) chargen (порт 19) Атакер может создать проблемы, фальсифицируя адрес отправителя и вынуждая две машины бесконечно обмениваться откликами друг с другом. Таким образом, может быть парализована вся сеть (ведь хакер может послать много таких пакетов). Например, хакер может имитировать посылку пакета от ЭВМ-A (порт chargen) к ЭВМ-B (порт echo). Эхо-служба ЭВМ-B пошлет отклик ЭВМ-A и т.д. 2000203 Snork attack. Регистрируются UDP-дейтограммы с портом назначения 135 (Microsoft Location Service), и отправитель с портом 7 (Echo), 19 (Chargen) или 135. Это попытка замкнуть две службы (если они разрешены/активированы) и заставить их бесконечно обмениваться пакетами друг с другом. Существует пэтч для блокировки таких атак (смотри сайт Microsoft). 2000204 Ascend Attack. Атака маршрутизаторов Ascend путем посылки UDP-пакета в порт 9. 2000205 Possible Fraggle attack initiated.Это не атака вашей ЭВМ. Это скорее попытка перегрузить систему третьей стороны. Это может быть также попытка выявить всех сетевых соседей. Internet поддерживает широковещательную адресацию. Это позволяет послать один "" сотням ЭВМ "". Эта техника позволяет ЭВМ оповестить окружение о своем присутствии. Атакер, используя технику, называемую "", атакует третью сторону. Атакер притворяется жертвой и посылает эхо-пакеты в субсеть. Каждая включенная ЭВМ откликнется "отправителю". Этот вид атаки был использован югославскими хакерами против сайтов в США и НАТО. Системы Firewall блокируют такие пакеты по умолчанию. Разные пакеты могут быть посланы ЭВМ, чтобы вызвать эхо-отклик. Сюда входят: ICMP Echo Используются стандартной командой 'ping' Применяется также в -атаке, которая подобна fraggle. Эхо-порт UDP, который перенаправляет трафик отправителю. Это первичный пакет, используемый для запуска атаки fraggle. Перенаправляет произвольный трафик отправителю Присылает значение текущего времени отправителю. Присылает отправителю "quote of the day" или "fortune cookie".
2000207	UDP short header. Заголовок UDP-дейтограммы содержит менее 8 байт (в надежде сломать программу-обработчик)
2000208	Saihyousen attack. Атака против ConSeal PC Firewall
2000209	W2K domain controller attack. Атакер посылает error-пакет вашей ЭВМ на UDP порт 464, а ваша система отвечает, возможно получение бесконечного цикла.
2000210	Echo_Denial_of_Service. Посылается UDP-пакет с номером порта отправителя и получателя равным 7.
2000211	Chargen_Denial_of_Service. Посылается UDP-пакет с номером порта отправителя и получателя равным 19.
2000301	TCP port scan.
2000302	TCP SYN flood.
2000303	WinNuke attack.
2000304	TCP sequence out-of-range.
2000305	TCP FIN scan. Разновидность TCP-сканирования. Однако хакер здесь пытается осуществить так называемое "FIN-сканирование". Он пытается закрыть несуществующее соединение сервера. Это ошибка, но системы иногда выдают разные результаты в зависимости от того, является ли данная услуга доступной. В результате атакер может получить доступ к системе.
2000306	TCP header fragmentation.
2000307	TCP short header.
2000308	TCP XMAS scan. Посылается TCP-сегмент с ISN=0 и битами FIN, URG и PUSH равными 1.
2000309	TCP null scan. Посылается TCP-сегмент с ISN=0 и битами флагов равными нулю.
2000310	TCP ACK ping.
2000311	TCP post connection SYN.
2000312	TCP FIN or RST seq out-of-range..
2000313	TCP OS fingerprint. Посылается необычная комбинация TCP-флагов с тем, чтобы посмотреть реакцию. А по реакции определить вид ОС. 2000314 NMAP OS fingerprint. 2000315 Zero length TCP option. 2000316 TCP small segment size.. 2000317 TCP SYN with URG flag. 2000318 TCP Invalid Urgent offset. 2000319 RFProwl exploit. 2000320 TCP data changed. 2000321 Queso Scan. Попытка определения версии ОС или прикладной программы 2000401 DNS zone transfer. 2000402 DNS cache poison. Атакер послал запрос DNS-серверу, который содержит также и отклик. Это может быть попыткой компрометировать DNS-серверов. Это может быть также результатом работы ISP, который перенаправляет своих клиентов на прокси-сервер. Это вероятнее всего вторжение в систему Для того чтобы улучшить рабочие параметры, DNS-серверы пытаются "кэшировать" имена локально. Серверы просматривают секции откликов всех пакетов, приходящих в систему. Они запоминают эти отклики на короткое время на случай, если кто-то еще нуждается в этой информации. Очевидной проблемой является случай, когда такой пакет содержит ложную информацию. В частности, кто-то может послать запрос в DNS, содержащий, кроме того, дополнительную информацию в секции отклика. Старые серверы воспринимают эту информацию, кэшируют ее, и выдают в ответ на запрос, если таковой поступит. (Новые DNS-серверы лишены этой дырки, но существует еще достаточно много старых серверов). Если ваш DNS-сервер обновлен, атака такого рода невозможна. 2000403 DNS name overflow. 2000404 DNS non-Internet lookup. DNS-запрос послан не DNS-серверу или запрос имеет некорректный формат. 2000405 DNS malformed. 2000406 DNS Internet not 4 bytes. 2000407 DNS HINFO query. 2000408 DNS spoof successful. 2000409 DNS IQUERY. 2000410 DNS I-Query exploit. 2000411 DNS Chaos lookup. 2000413 NetBIOS names query. 2000414 DNS spoof attempt. 2000415 DNS NXT record overflow. 2000416 DNS null. DNS-запрос не содержит ни поля запросов, ни поля ответов ни поля дополнительной информации. 2000417 DNS BIND version request. Сервер BIND DNS содержит в своей базе данных запись CHAOS/TXT с именем "VERSION.BIND". Если кому- то нужна эта запись, присылается версия программы BIND soft. Такой запрос сам по себе не является атакой, но может являться разведывательным рейдом. Однако, если возвращается версия типа "4.9.6-REL" или "8.2.1", это указывает, что у вас установлена версия с хорошо известной дыркой, связанной с переполнением буфера. 2000418 AntiSniff DNS exploit. Программа AntiSniff может быть использована путем посылки специального DNS-кадра. В случае успеха, атакер может использовать программу, работающую в системе, где работает AntiSniff. AntiSniff представляет собой программу, которая разработана L0pht Heavy Industries в июле 1999. Атакер может использовать L0pht AntiSniff для получения информации о сети, которая может оказаться для него полезной при последующих атаках. Атакер может также использовать L0pht AntiSniff для определения положения компрометированных ЭВМ, переведенных в режим 6 (sniffing), которые могут им позднее использоваться. 2000419 Excessive DNS requests. 2000420 DNS ZXFR. Предпринята попытка осуществить зонный обмен DNS с транспортным сжатием, что само по себе нормально (популярный алгоритм "gzip"). Подобно всем зонным обменам, это позволяет удаленному атакеру сформировать карту вашей сети. Такой обмен может быть частью атаки, если поступает извне. 2000421 DNS TSIG name overflow. 2000422 DNS name overflow contains %. 2000423 DNS name overflow very long. 2000501 SMB malformed. Существует ошибка в старой версии SMB (система Microsoft для совместного использования файлов и принтеров в сети). Эта ошибка может быть использована при авторизации, путем посылки специально сформированных пакетов. При реализации этого трюка машина крэшится. Данная атака может быть предпринята успешно для систем Windows NT 4.0 SP4 и Windows 95 (все версии). Заметим, что имеются пэтчи для всех систем. Для того чтобы дырка работала, "File and Print Sharing" должно быть разрешено. 2000502 SMB empty password. 2000503 SMB I/O using printer share. 2000504 SMB password overflow. 2000505 SMB file name overflow. 2000506 SMB Unicode file name overflow. 2000507 SMB unencrypted password. 2000508 RFParalyze exploit. 2000600 HTTP Attack. 2000601 HTTP URL overflow. 2000602 HTTP cgi starting with php. Специально сконструированный URL может позволить нежелательный доступ к CGI на сервере 2000603 HTTP URL directory traversal/climbing. Ситуация выглядит так, как будто атакер пытается прочесть посторонние файлы вашей системы. Обычная ошибка web-броузера заключается в том, что хакер может специфицировать URL, который выглядит как /../../../foo/bar.txt. Эта атака удается, так как программист не осуществляет двойной проверки URL, чтобы убедиться, корректен ли файл web-сайта. Сигнатурой такой атаки может быть наличие в URL последовательности ../... Иногда такого рода атака может быть имитирована некорректными связями, размещенными на странице. Это говорит о некорректной конфигурации. Во-первых, проверьте параметры URL, чтобы выяснить к какому файлу намерен получить доступ атакер. Затем проверьте, получил ли атакер доступ к файлу. Если это действительно критичный файл, и атакер был успешен, необходимо предпринять срочные действия. Например, если атакер получил доступ к файлу паролей, необходимо заменить все пароли. Следует также проверить является ли версия сервера новейшей и использованы ли все существующие пэтчи безопасности. Большинство таких атак предпринимается против "встроенных" web-серверов (т.e. web-серверов, добавленных в качестве части другого программного продукта), а не против реальных web-серверов типа Apache и IIS. 2000604 HTTP asp with . appended. 2000605 HTTP cgi with ~ appended. 2000606 HTTP URL has many slashes. 2000607 HTTP URL with ::$DATA appended. Предпринята попытка доступа к файлу с завершающей последовательностью ::$DATA. Некоторые серверы в этом случае возвращают исходный файл asp, вместо того, чтобы его (asp) исполнить, таким образом атакер получает критическую информацию о сервере. Исходные тексты программы сервера часто содержат пароли, имена скрытых файлов и т.д. 2000608 HTTP GET data overflow. 2000609 Данные HTTP CGI содержат ../../../... Данные, переданные в URL, имеют подозрительный проход, содержащий ../../../..; Этот проход может быть использован для доступа к привилегированным файлам. Атакер пытается добраться по дереву каталогов до нужных ему файлов. Некоторые приложения Web используют проходы, содержащие ../../../.. . Вам следует рассмотреть URL и аргумент GET с целью проверки их корректности. Если проход в аргументе GET, указывает на попытку доступа к привилегированным данным, возможно ваш сервер скомпрометирован. 2000610 HTTP URL with blank appended. 2000611 HTTP GET data with repeated char. 2000612 IIS Double-Byte Code attempt. Специально сформированный URL, который может позволить нежелательный доступ . Выполняется попытка доступа к URL с завершающими %81 - %FE. Некоторые серверы возвращают в этом случае исходный файл, а не выполняют его, таким образом предоставляется атакеру критическая информация о сервере. Исходный текст программы сервера часто содержит скрытые пароли, имена файлов или данные об ошибках в программе. 2000613 HTTP HOST: repeated many times. 2000614 HTTP URL contains old DOS filename. 2000615 HTTP ACCEPT: field overflow. 2000616 HTTP URL contains /./. 2000617 HTTP URL contains /.... 2000618 HTTP GET data contains /.... 2000619 HTTP URL scan. 2000620 Whisker URL fingerprint. 2000621 Web site copying. 2000622 HTTP Authentication overflow. 2000623 HTTP POST data contains ../../../... Некоторые Web-серверы используют "скрытое" поле формы, содержащее имя файла, чтобы управлять работой программы сервера. Однако несмотря на то, что поле скрытое, оно может быть переписано. Когда форма поступает серверу, он может пренебречь проверкой корректности значения поля. Таким образом, посылая некорректную форму, хакер может получить доступ к файлам Web-сервера, содержащим критическую информацию. 2000624 HTTP POST data contains /.... 2000625 HTTP URL with repeated char. 2000626 HTTP POST data with repeated char. 2000627 HTTP URL bad hex code. 2000628 HTTP URL contains %20. 2000629 HTTP User-Agent overflow. 2000630 HTTP asp with \ appended. Произошла попытка доступа к файлу asp с завершающим символом \. В некоторых ситуациях, вместо исполнения программы asp будет возвращен исходный asp-файл. Это раскроет атакеру критическую информацию о сервере. Исходный текст программы сервера часто содержит пароли, скрытые имена файлов или ошибки, которые в такой ситуации относительно легко найти. Хакер может затем использовать эту скрытую (hidden) информацию для вскрытия сервера. 2000631 URL with repeated .. 2000632 HTTP JavaServer URL in Caps. 2000633 HTTP URL with +.htr appended. 2000634 HTTP path contains *.jhtml or *.jsp. 2000635 HTTP POST data contains script. 2000636 HTTP HOST: field overflow. 2000638 HTTP Cookie overflow. 2000639 HTTP UTF8 backtrack. 2000640 HTTP GET data contains script. 2000641 HTTP login name well known. 2000642 HTTP DAV PROPFIND overflow. 2000643 SubSeven CGI. 2000644 Repeated access to same Web service. 2000645 HTTP URL with double-encoded ../. 2000646 HTTP field with binary. 2000647 HTTP several fields with binary. 2000648 HTTP CONNECTION: field overflow. 2000700 POP3 Attack. 2000701 POP3 USER overflow. 2000702 POP3 password overflow. 2000703 POP3 MIME filename overflow. 2000704 POP3 command overflow. 2000705 POP3 AUTH overflow. 2000706 POP3 RETR overflow. 2000707 POP3 MIME filename repeated chars. 2000708 POP3 MIME filename repeated blanks. 2000709 POP3 Date overflow. 2000710 POP3 APOP name overflow. 2000711 POP3 false attachment. 2000800 IMAP4 Attack. 2000801 IMAP4 user name overflow. 2000802 IMAP4 password overflow. 2000803 IMAP4 authentication overflow. 2000804 IMAP4 command overflow. 2000805 IMAP4 Parm Overflow. 2000901 Telnet abuse. 2000902 Telnet login name overflow. 2000903 Telnet password overflow. 2000904 Telnet terminal type overflow. 2000905 Telnet NTLM tickle. 2000906 Telnet Bad Environment. 2000907 Telnet Bad IFS. В UNIX, переменная "IFS" специфицирует символ, разделяющий команды. Если значение этой переменной изменено, тогда система детектирования вторжения не будет способна корректно интерпретировать команды. Более того, кто-либо может изменить эту переменную для того, чтобы модифицировать работу некоторых скриптов ядра. В частности плохой IFS станет разграничителем, используемым при разборе любых вводов, таких как имена файлов или DNS-имена. В этом случае, нужно установить IFS соответствующим символу '/' или '.'. Вообще, если вы хотите жить немного спокойнее, лучше заблокировать применение telnet, предложив пользователям перейти на SSH.
2000908	Telnet Environment Format String Attack. В районе августа 2000, выявлено большое число атак типа "". Эти атаки связаны с попыткой проникнуть в Telnet-машины путем посылки некорректных переменных окружения (environmental variables with format commands).
2000909	Telnet RESOLV_HOST_CONF. Переменная окружения RESOLV_HOST_CONF посылается с привлечением поля опций Telnet. Это поле не должно никогда изменяться таким способом. Это может означать попытку получения доступа к критическим файлам типа паролей и т.д.
2000910	Telnet bad TERM. Совершена попытка исказить "TERM" Telnet. Клиент Telnet может эмулировать многие виды терминалов текстового типа. Клиент передает эту информацию серверу с помощью переменной "TERM" или команды "term-type". Если обнаружено необычное значение этой переменной, возможно предпринята атака против вашей системы.
2000911	Telnet bad TERMCAP.
2000912	Telnet XDISPLOC.
2000913	Telnet AUTH USER overflow.
2000914	Telnet ENV overflow.
2000915	Telnet login name well known.
2000916	Telnet Backdoor. Атакер пытается воспользоваться известным именем/паролем "задней" двери telnet . Протокольный анализатор извлекает login name и пароль из входной строки Telnet и сравнивает их со списком известных параметров доступа для задней двери telnet. Некоторые из них приведены ниже: wh00t! Пароль задней двери предоставляемый rootkit для Linux, разработанного в 1994 . lrkr0x Пароль задней двери предоставляемый Rootkit I для Linux, разработанного в 1996 satori Rootkit IV для Linux. rewt Задняя дверь пользовательского аккоунта, которая предоставляет root-привилегии. h0tb0x Пароль задней двери для FreeBSD rootkit 1.2 (1/27/97).
2001000	SMTP Attack.
2001001	SMTP pipe in mail address. кто-то пытается компрометировать e-mail сервер путем посылки исполняемого кода shell внутри e-mail адреса. Это имеет целью компрометировать e-mail сервер, а также субсистему, обрабатывающую заголовки почтового сообщения. Ниже приводится пример SMTP-сессии с попыткой реализации такой атаки: HELO MAIL FROM: |/usr/ucb/tail|/usr/bin/sh RCPT TO: root DATA From: attacker@example.com To: victim@example.com Return-Receipt-To: |foobar Subject: Sample Exploit
2001002	SMTP DEBUG command. Кто-то сканирует вашу систему с целью выявления ее уязвимости. В 1988, червь Morris уложил Интернет Internet. Одним из путей распространения червя являлась программа sendmail. Sendmail поддерживала нестандартную команду "DEBUG", которая позволяет любому получить контроль над сервером. Червь Morris автоматизировал этот процесс для распространения через системы sendmail Internet. Сейчас маловероятно, что вы найдете такую старую почтовую систему. Следовательно, такая атака будет означать, что кто-то использует универсальный сканер уязвимости. Иногда система может выйти из синхронизма (сбой в ISN), что вызывает большие потери пакетов. В таких условиях по ошибке может быть запущена команда DEBUG. Например, если вы работаете с версией сервера для системы 486, который обрабатывает большое количество e-mail, такая десинхронизация может произойти. Уязвимой системой является Sendmail/5.5.8.
2001003	SMTP login name overflow.
2001004	SMTP EXPN command.
2001005	SMTP VRFY command.
2001006	SMTP WIZ command.
2001007	SMTP Too many recipients.
2001008	SMTP corrupted MAIL command.
2001009	SMTP email name overflow.
2001010	SMTP corrupted RCPT command.
2001011	SMTP relay attempt. Предпринята попытка использования SMTP в качестве ретранслятора сообщений - это может случиться, когда спамер некорректно использует SMTP-сервер. Это одна из наиболее успешных атак на Internet. Спамер регулярно ищет в Интернет ретранслирующие e-mail сервера. Примерно половина всех e-mail серверов поддерживают ретрансляцию в той или иной форме.
2001012	SMTP command overflow.
2001013	SMTP mail to decode alias. Обнаружено сообщение, адресованное пользователю с именем decode. Это может быть попыткой взломать почтовый сервер, или это может быть частью сканирования системы. Это достаточно старый трюк, выявленный в 1990. Системы UNIX позволяют посылать почту клиенту с именем decode, чтобы передать сообщение не клиенту, а программе uudecode. Атакер может попытаться таким образом переписать файлы таким образом, чтобы проникнуть в систему. Эта дырка связана с файлом /etc/aliases, содержащим строку типа: decode: |/usr/bin/uudecode Сейчас, такой тип вторжения может проявиться лишь в случае универсального сканирования с целью выявления уязвимости вашей системы. Например, атакер пытается передать по каналу uuencoded-файл после команды DATA. HELO MAIL FROM: test@example.com RCPT TO: decode DATA begin 644 /usr/bin/.rhosts $*R`K"@`` ` end . QUIT Этот пример пытается атаковать систему путем записи строки "+ +" в файл ".rhosts". Это будет указывать системе, что следует доверять любому, кто вошел в нее через программу типа 'rlogin'. Этот вид атаки существенен только для почтовых серверов, работающих под UNIX. Просмотрите файл "aliases", размещенный в /etc/aliases. Проверьте, нет ли строк типа: decode: |/usr/bin/uudecode uudecode: |/usr/bin/uuencode -d Удалите эти строки. Заметим, что новые системы не допускают такой возможности.
2001014	SMTP mail to uudecode alias.
2001015	SMTP too many errors.
2001016	SMTP MIME file name overflow.
2001017	SMTP uucp-style recipient.
2001018	SMTP encapsulated relay.
2001019	STMP encapsulated Exchange relay. Spam-атака. Выявляется инкапсулируемый почтовый адрес вида . Некоторые версии Microsoft Exchange не способны проверять эти типы адресов, таким образом, они могут использоваться спамерами для посылки неавторизованной почты.
2001020	SMTP mail to rpmmail alias.
2001021	SMTP MIME name overflow.
2001022	SMTP MIME filename repeated chars.
2001023	SMTP MIME filename repeated blanks.
2001024	SMTP ETRN overflow.
2001025	SMTP Date overflow.
2001026	SMTP Recipient with trailing dot.
2001027	SMTP FROM: field overflow.
2001028	SMTP MIME null charset. Обнаружено незнакомое почтовое сообщение, вероятно сконструированное, чтобы разрушить почтовый сервер. В заголовки "Reply-To:" сообщения встраиваются исполняемые Shell и PERL коды. Когда система откликается, эти коду будут исполнены. Например, старые версии list-сервера MAJORDOMO исполняют любой PERL-скрипт, который вставлен в это поле.
2001030	SMTP ENVID overflow.
2001031	SMTP false attachment.
2001032	SMTP Expn Overflow.
2001033	SMTP Vrfy Overflow.
2001034	SMTP Listserv Overflow.
2001036	SMTP Auth Overflow.
2001040	SMTP Xchg Auth.
2001041	SMTP Turn.
2001101	Finger.
2001102	Finger forwarding. Предпринята попытка использования программы finger для переадресации запроса другой системе. Это часто делается атакерами, чтобы замаскировать свою идентификацию. Finger поддерживает рекурсивные запросы. Запрос типа "rob@foo@bar" просит "bar" сообщить информацию о "rob@foo", заставляя "bar" послать запрос "foo". Эта техника может использоваться для сокрытия истинного источника запроса. Finger является опасным источником информации и по этой причине должен быть заблокирован в /etc/inetd.conf.
2001103	Finger forwarding overflow.
2001104	Finger command.
2001105	Finger list.
2001106	Finger filename.
2001107	Finger overflow.
2001108	Finger search. Демон "cfinger" позволяет осуществлять поиск любых или всех имен пользователей, при вводе "search.*". Эта возможность поиска предоставляет атакеру легкий способ пронумеровать всех пользователей системы. Широкополосные сканеры (напр. CyberCop Scanner, ISS Scanner) осуществляют сканирование этого типа. Сигнатурой для этого вида атаки является наличие строки "search.*" в качестве имени пользователя.
2001109	Finger Backdoor. Кто-то пытается повторно войти в систему через известную заднюю дверь в finger. Раз система была компрометирована, атакеры могу оставит для себя открытую "потайную" дверь, через которую они смогут войти, когда захотят. Например, одна потайная дверь допускает посылку finger команды "cmd_rootsh", которая открывает shell с привилегиями суперпользователя. Заметим, что если потайная дверь действительно имеется, ваша система уже была скомпрометирована. В настоящее время, все известные потайные двери finger существуют только в системах UNIX. Если вы столкнулись с такой проблемой то, во-первых, просмотрите информацию откликов, которая может быть в наличии. Если вы обнаружили какие-то уведомления об ошибках, то вероятно попытка вторжения не была успешной (но не обольщайтесь). Во-вторых, если вы озабочены возможностью наличия потайной двери в системе, исполните команду finger сами. Чтобы устранить уязвимость данного вида, следует, во-первых, рассмотреть возможность удаления услуги finger вообще. Это опасная услуга, которая предоставляет полезную информацию атакерам. Во-вторых, если вы чувствуете, что система компрометирована, следует заново инсталлировать операционную систему. Поищите потайную дверь в списке пользователей. Трудно представить, что какой-то пользователь в вашей системе имеет имя "cmd_shell". Многие широкодиапазонные сканеры ищут такие потайные двери.
2001110	Finger Scan. Производится сканирование известных из Finger имен пользователей с целью получения персональной информации. Например, если вы направляете запрос finger "jsmith", вы вероятно ищите данные о "Jane Smith". В безопасных сетях, любое использование finger подозрительно, так как оно может раскрыть важную информацию о пользователе. Однако, существует в системе большое число не пользовательских аккоунтов, таких как "adm", "bin" или "demo". Попытки Finger обратиться к этим аккоунтам указывают, что кто-то использует протокол finger для того, чтобы сканировать сервер с целью получения более существенной информации. В настоящее время, finger работает на UNIX-системах. Чтобы забыть об этих проблемах, заблокируйте finger. Если он работает, атакеры могут получить нужные им данные, а за помощь им вам не платят.
2001111	Finger Enumeration. Зафиксированы подозрительные команды finger. Finger используется для поиска информации о пользователях. Некоторые системы допускают множественный поиск пользователей. Здесь возможны некорректности. Например, запрос finger о пользователе с именем "e" выдаст список всех пользователей в системе, содержащими "e" в своем имени. Некоторые системы finger допускают также спецификацию множественных имен. Это означает, что finger для "a b c d e f...x y z" перечисляет всех пользователей в системе. В настоящее время, finger работает в основном на системах UNIX. Чтобы забыть об этих проблемах, заблокируйте finger. Если он работает, атакеры могут получить нужные им данные.
2001201	TFTP file not found.
2001202	TFTP file name overflow.
2001203	TFTP Traversal.
2001204	TFTP Exe Transfer.
2001205	TFTP Web Transfer.
2001206	TFTP Echo Bounce.
2001301	FTP invalid PORT command. Если вы такое обнаружили, это означает, что совершается попытка вторжения в вашу FTP-систему. Немногие ЭВМ допускают такую атаку. Команда "PORT" является частью протокола FTP но обычно незаметна для пользователя, хотя он часто и получает статусные сообщения "PORT command successful". Это уведомляет противоположную сторону о том, кода следует направлять данные. Эта команда форматируется в виде списка из 6 чисел, разделенных запятыми. Например: PORT 192,0,2,63,4,01 Данная команда сообщает противоположной стороне, что данные следует отправлять по адресу 192.0.2.63, порт 1025. Если эта команда искажена, то вероятно атакер пытается компрометировать FTP-сервис. Однако, так как большинство FTP-сервисов противостоит этому типу атаки, шансов у хакера в этом варианте немного.
2001302	FTP PORT bounce to other system.
2001303	FTP PORT restricted.
2001304	FTP CWD ~root command.
2001305	FTP SITE EXEC command. Старые версии FTP-серверов поддерживают эту команду, которая разрешает нежелательный доступ к серверу. В версиях wu-ftpd ниже 2.2, имеется возможность исполнения программы (об этом хакер может только мечтать) . Ниже показана сессия, где "robert" имеет легальный аккоунт в системе и пытается реализовать режим строчно-командного доступа к shell. 220 example.com FTP server (Version wu-2.1(1) ready. Name (example.com:robert): robert 331 Password required for robert. Password: foobar 230 User robert logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> quote "site exec cp /bin/sh /tmp/.runme" 200-cp /bin/sh /tmp/runme ftp> quote "site exec chmod 6755 /tmp/.runme" 200-chmod 6755 /tmp/runme ftp> quit 221 Goodbye. Теперь пользователь авторизован и может работать с shell на уровне привилегий root в каталоге /tmp.
2001306	FTP USER name overflow.
2001307	FTP password overflow.
2001308	FTP CWD directory overflow.
2001309	FTP file name overflow.
2001310	FTP command line overflow.
2001311	FTP pipe in filename. Совершена попытка исполнить программу на FTP-сервере. Допускающее это ошибка имеется во многих FTP-демонах около 1997, таких что, если перед именем файла присутствует символ PIPE (|), сервер пытается исполнить программу имя которой следует за ним. Так как FTP-сервер обычно работает с привилегией root, может произойти его компрометация. Проверьте, что у вас работает новейшая версия сервера.
2001312	FTP MKD directory overflow.
2001313	ProFTPD snprintf exploit.
2001314	FTP SITE PSWD exploit.
2001315	FTP compress exec exploit.
2001316	FTP file exec exploit.
2001317	FTP command too long.
2001318	FTP data too long.
2001319	FTP NLST directory overflow.
2001320	FTP SITE ZIPCHK metacharacters.
2001321	FTP SITE ZIPCHK buffer overflow.
2001322	FTP SITE EXEC exploit.
2001323	FTP PrivilegedBounce. Кто-то пытается нарушить безопасность FTP-сервиса, чтобы сканировать другие ЭВМ. Если атака FTP используется при одновременной спецификации привилегированного порта, можете не сомневаться - это сетевая атака. Возможно, что FTP-переадресация на непривилегированный порт является результатом FTP-прокси. По этой причине комбинированная атака рассматривается как отдельная сигнатура. Это позволяет атакеру маскировать свою сетевую идентичность. Возможно также, что атакер, используя эту технику, может обойти некоторые плохо конфигурированные фильтры пакетов или firewalls. Например, если ваш mail-сервер допускает соединения посредством telnet с вашим внутренним FTP-сервером, а с внешними ЭВМ из Internet не допускает, атакер сможет соединиться с вашим telnet-портом на вашем SMTP методом переадресации через ваш FTP-сервер. К системам допускающим такую атаку относятся SunOS 4.1.x, Solaris 5.x, большинство систем, работающих со старыми FTP-серверами. Чтобы покончить с такого рода угрозой раз и навсегда. Просмотрите, какие ЭВМ и порты вовлечены в этот процесс. Если это ваши ЭВМ, проконтролируйте, как это реализовано. Если же это не ваша ЭВМ, убедитесь, что администратор этой машины, видит, что в соединении участвует ваш FTP-сервер, и если атака осуществлена, ваша машина будет выглядеть, как источник этой атаки. Вы можете провзаимодействовать с этим администратором или по крайней мере записать logs оригинального источника атаки. После этих дипломатических шагов вам следует установить новую версию FTP-сервера, где данная ошибка исправлена, например, wu-ftpd 2.4.2 beta 15 или более новую.
2001324	FTP Site Exec DotDot. Попытка неавторизованного доступа. Некоторые версии wu-ftpd позволяют использовать команду site exec для удаленных машин. Путем предоставления прохода с определенными параметрами, удаленный пользователь может исполнить произвольные команды на FTP-сервере. Эта атака позволяет атакующему выполнять команды на атакуемой машине. Это может привести к получению им доступа root-уровня. Такой дефект имеют системы wu-ftpd 2.4.1 и ранее. Чтобы защитить себя от таких атак, просмотрите команды, которые атакер использовал. Если они представляют угрозу для атакуемой ЭВМ, можете считать машину скомпрометированной. Обновите программное обеспечение FTP-сервера или замените его вообще.
2001325	FTP Site Exec Format Attack.
2001326	FTP Site Exec Tar.
2001327	FTP Site Chown Overflow.
2001328	FTP AIX Overflow.
2001329	FTP HELP Overflow.
2001330	FTP Glob Overflow.
2001331	FTP Pasv DoS.
2001332	FTP Mget DotDot.
2001401	RWHO host name overflow.
2001501	Back Orifice scan. Кто-то сканирует вашу систему на предмет троянского коня "Back Orifice". Back Orifice сканы наиболее частые атаки, встречающиеся в Internet. Ваша машина просканирована, но еще не выбрана для атаки. Это означает, что хакер сканирует тысячи ЭВМ в Interent, надеясь найти одну, которая была скомпрометирована посредством Back Orifice. Хакер не обязательно охотится именно на вашу ЭВМ. Большинство взломов происходит путем установки хакером инфицированных программ или документов в Internet в надежде, что какой-то неосторожный клиент скопирует и запустит их у себя. Хакер сканирует затем Internet и ищет эти скомпрометированные ЭВМ. Но даже, если ваша машина была скомпрометирована программой Back Orifice, ваша субсистема firewall может заблокировать доступ к ней.
2001502	Netbus response.
2001503	Quake backdoor.
2001504	HP Remote watch.
2001505	Back Orifice response.
2001506	Back Orifice ping.
2001507	PCAnywhere ping. Кто-то пингует систему для того чтобы проверить, работает ли PCAnywhere. Это может быть атака, но может быть и случайный инцидент. PCAnywhere является продуктом Symantec, который позволяет осуществить удаленное управление ЭВМ. Она является очень популярной в Internet для этих легальных целей, позволяя администраторам удаленно контролировать серверы. Хакеры часто сканируют Internet с целью поиска машин, поддерживающих этот продукт. Многие пользователи используют пустые пароли или пароли, которые легко угадать (например слово "password"). Это предоставит легкий доступ хакеру. Если хакер захватил контроль над машиной, он не только могут украсть информацию, но и использовать эту машину для атаки других ЭВМ в Интернет. Случайные сканирования клиентами PCAnywhere обычно видны со стороны соседей. Программа инсталлирует иконку, названную "NETWORK", которая сканирует локальную область. Хотя эти сканы не содержат враждебных намерений, они могут создавать дискомфорт. Чтобы проверить, что на самом деле имеет место, следует рассмотреть IP-адрес атакер. Если IP-адрес относится к локальному сегменту (т.e. подобен вашему IP-адресу), тогда ничего страшного. В противном случае (адрес внешний) - имеет место атака вашей системы. PCanywhere сканирует то, что называется диапазоном "класса C", например, 192.0.2.0 - 192.0.2.255. Если вы не работаете с PCAnywhere, тогда проблем нет. В противном случае, читайте советы по обеспечению безопасности сервера PCAnywhere.
2001508	ISS Ping Scan.
2001509	ISS UDP scan.
2001510	Cybercop FTP scan.
2001511	WhatsUp scan.
2001512	Back Orifice 2000 ping.
2001513	Back Orifice 2000 auth.
2001514	Back Orifice 2000 command.
2001515	Back Orifice 2000 response.
2001517	Scan by sscan program.
2001518	phAse Zero trojan horse activity. Возможная попытка вторжения. Программа phAse Zero обладает всеми стандартными особенностями троянского коня, включая возможность выгружать и загружать файлы в ЭВМ с помощью FTP, исполнять программы, стирать и копировать файлы, а также читать и записывать в конфигурационную базу данных (registry). Здесь имеется функция 'Trash Server', которая удалит все файлы из каталога вашей системы Windows. phAse Zero работает под Windows 95, 98 и Windows NT.
2001519	SubSeven trojan horse activity.
2001520	GateCrasher trojan horse activity.
2001521	GirlFriend trojan horse activity.
2001522	EvilFTP trojan horse activity. Неавторизованная попытка вторжения. Троянский конь EvilFTP является одним из многих программ подобного рода, который может использовать атакер для доступа к вашей компьютерной системы без вашего ведома. Когда программа, содержащая троянского коня работает, EvilFTP инсталлирует FTP-сервер на порт12346 с login "yo" паролем "connect." Этот троянский конь при инсталляции в удаленной системе позволяет атакеру выгружать и загружать файлы для системы, где он инсталлирован.
2001523	NetSphere trojan horse activity.
2001524	Trinoo Master activity.
2001525	Trinoo Daemon activity.
2001526	NMAP ping. Для проверки вашей системы на уязвимость используется программа NMAP. NMAP -очень популярная программа, используемая хакерами для сканирования Internet. Она работает под Unix, и имеет много конфигурационных опций и использует несколько трюков, чтобы избежать детектирования системами, детектирующими вторжение. NMAP не позволяет хакеру вторгнуться в систему, но допускает получение им полезной информации о конфигурации системы и доступных услугах. Программа часто используется как прелюдия более серьезной атаки.
2001527	NetSphere Client. Активность клиента NetSphere. Это указывает, имеется пользователь в вашей сети, который применил NetSphere для хакерства. Это не должно быть заметно клиентам, если только они сами не работают с NetSpheres.
2001528	Mstream agent activity.
2001529	Mstream handler activity.
2001530	SubSeven password-protected activity.
2001531	Qaz trojan horse activity.
2001532	LeakTest trojan horse activity.
2001533	Hack-a-tack trojan horse activity.
2001534	Hack-a-tack trojan horse ping.
2001535	Bionet trojan horse activity.
2001536	Y3K trojan horse ping.
2001537	Y3K trojan horse activity.
2001601	FTP login failed.
2001602	HTTP login failed.
2001603	IMAP4 login failed.
2001604	POP3 login failed.
2001605	rlogin login failed.
2001606	SMB login failed.
2001607	SQL login failed.
2001608	Telnet login failed.
2001609	SMTP login failed.
2001610	PCAnywhere login failed.
2001611	SOCKS login failed.
2001612	VNC login failed.
2001701	rpc.automountd overflow.
2001702	rpc.statd overflow.
2001703	rpc.tooltalkd overflow.
2001704	rpc.admind auth.
2001705	rpc.portmap dump.
2001706	rpc.mountd overflow.
2001707	RPC nfs/lockd attack.
2001708	rpc.portmap.set.
2001709	rpc.portmap.unset.
2001710	rpc.pcnfs backdoor.
2001711	rpc.statd dotdot file create.
2001712	rpc.ypupdated command.
2001713	rpc.nfs uid is zero.
2001714	rpc.nfs mknod.
2001715	rpc.nisd long name.
2001716	rpc.statd with automount.
2001717	rpc.cmsd overflow.
2001718	rpc.amd overflow.
2001719	RPC bad credentials.
2001720	RPC suspicious credentials.
2001721	RPC getport probe.
2001722	rpc.sadmind overflow.
2001723	rpc.SGI FAM access.
2001724	RPC CALLIT unknown.
2001725	RPC CALLIT attack.
2001726	RPC CALLIT mount.
2001727	rpc.bootparam whoami mismatch.
2001728	RPC prog grind.
2001729	RPC high-port portmap.
2001730	RPC ypbind directory climb.
2001731	RPC showmount exports.
2001732	RPC selection_svc hold file.
2001733	RPC suspicious lookup.
2001734	RPC SNMPXDMID overflow.
2001735	RPC CALLIT ping.
2001736	RPC yppasswdd overflow.
2001737	rpc.statd Format Attack.
2001738	RPC Sadmind Ping.
2001739	RPC Amd Version.
2001801	IRC buffer overflow.
2001802	SubSeven IRC notification.
2001803	IRC Trinity agent.
2001804	Y3K IRC notification.
2001901	IDENT invalid response. Чужой сервер пытается использовать identd клиента. Многие программы осуществляют реверсивные lookups IDENT. Эти программы уязвимы к атакам, когда сервер присылает некорректный отклик.
2001902	IDENT scan.
2001903	IDENT suspicious ID.
2001904	IDENT version.
2001905	IDENT newline.
2002001	SNMP Corrupt.
2002002	SNMP Crack. Обнаружено большое число строк community (паролей), которые индицируют попытку вскрыть систему контроля паролей. Большое число сообщений SNMP с различными строками community за ограниченный период времени должны рассматриваться как подозрительная активность, и как попытка подобрать корректное значение поля community. SNMP(Simple Network Management Protocol) используется для мониторирования параметров оборудования. Однако, это крайне небезопасный протокол, и ничто не препятствует простому подбору пароля путем простого перебора. Следует конфигурировать систему так, чтобы она была доступна со стороны ограниченного числа машин. Рекомендуется также использовать максимально возможно длинные строки community, что позволит зарегистрировать подбор до того, как он успешно завершится.
2002003	SNMP backdoor. Атакер пытается использовать известную "потайную дверь" сетевого оборудования. Однако, многие приборы имеют пароли для "потайной двери", которые могут использоваться для обхода нормальных проверок, предусмотренных нормальной системой обеспечения безопасности. Скрытые и недокументированные строки community имеются во многих субагентах SNMP, которые могут позволить атакерам поменять важные системные параметры. Удаленные атакеры могут убить любой процесс, модифицировать маршруты, или заблокировать сетевые интерфейсы. Важно то, что атакер может выполнить апосредовано произвольные команды, требующие привилегий суперюзера.
2002004	SNMP discovery broadcast. Атакер посылает команду SNMP GET по широковещательному адресу. Это может быть попыткой определить, какие системы поддерживают различные возможности SNMP. Это часто дает полную информацию об управляемом приборе, и иногда может предоставить полный контроль над прибором. В то же время, SNMP крайне небезопасный протокол, с легко угадываемым паролем. В результате, он является популярным протоколом для хакеров.
2002005	SNMP sysName overflow.
2002006	SNMP WINS deletion. Совершена попытка стереть записи WINS через интерфейс SNMP сервера. Это может быть попытка реализовать Denial-of-Service (DoS) или просканировать систему безопасности. Клиенты Windows контактируют с системой WINS для того, чтобы найти серверы. Многие системы уязвимы для атак при помощи SNMP-команд, посланных серверу для того, чтобы стереть записи. Это не взламывает сервер, но после стирания записи в базе данных, клиенты и серверые смогут более найти друг друга. Однако этот отказ обслуживания (DoS) может предварять другие атаки. Это может быть частью широко диапазонного сканирования с целью поиска слабых точек в сети. Эта атака может быть против систем, где нет работающих SNMP или WINS.
2002007	SNMP SET sysContact. Совершена попытка удаленно установить поле sysContact через SNMP. Это вероятно сканирование уязвимых мест вашей системы. Группа SNMP "system" используется всеми MIB. Она часто сканируется хакерами при предварительной разведке. Одним из способов сканирования является выполнение команд SET для поля "sysContact" для того, чтобы просмотреть, реагирует ли какая-либо система. Такие SET часто используют для взлома хорошо известные пароли/communities.
2002008	SNMP lanmanger enumeration.
2002009	SNMP TFTP retrieval.
2002010	SNMP hangup. Совершена попытка подвесить пользователя коммутируемой телефонной сети с помощью протокола SNMP. Некоторые типы сетевого оборудования (Ascend, Livingston, Cisco, etc.) могут допускать такое подвешивание пользователей. Это может быть обычным отказом обслуживания (DoS) в chat-комнатах и при играх в реальном времени. Один участник в chat-комнате может не любить другого. Он может взять IP-адрес жертвы, затем осуществлять поиск, пока не найдут прибор доступа, через который подключен клиент телефонной сети.
2002011	SNMP disable authen-traps. Совершена попытка заблокировать трэпы неудач SNMP-аутентификации, возможно с целью замаскировать активность хакера. Если строка community некорректна, прибор может послать на консоль управления трэп "authentication-failure". Эти строки community не управляют доступом всего SNMP-агента MIB. Вместо этого, они управляют "видами" MIB: различные строки community могут позволять управление различными частями MIB. Предположим сценарий, где атакер желает взломать строку community, отвечающую за секцию MIB поставщика. Это включает множество (возможно миллионы) попыток выяснить правильный пароль. Следовательно, чтобы избежать оповещений об атаке, нападающий должен заблокировать трэпы, которые могут поступить на консоль.
2002012	SNMP snmpdx attack. Совершена попытка заменить Sun Solstice Extension Agent, используя SNMP. Это может быть попытка вскрыть систему. Sun Solaris 2.6 поставляется со встроенной SNMP. В этот пакет входит возможность "extension agents": агенты, которые подключены к первичному SNMP-агенту для управления другими частями системы. Следует просмотреть log-book b jndtnbnm на вопросы: Имеется ли платформа управления, которая может выполнять подобные операции? Является ли строка "community" одной из "печально" известных для Solaris (в особенности "all private")? Параметр "val" содержит имя программы, которая будет исполнена. Выглядит ли это как демон или выглядит ли она как программа, предназначенная для компрометации системы? Типичными вариантами компрометации является создание xterm или скрипта, который изменяет /etc/passwd.
2002013	SNMP 3Com communities. Совершена попытка прочесть строку community/пароля устройства 3Com с помощью SNMP. Это может быть попыткой проникновения в систему. Многие старые версии оборудования 3Com содержат дефекты, которые делают строку community/пароля общедоступной. Атакер, чтобы получить пароли, может прочесть специфические таблицы, используя строку community+"public". После этого атакер получает полный контроль над прибором. Такого рода атаки возможны для хабов 3Com SuperStack II версий ранее 2.12, карт HiPer Arc, с кодами выпуска ранее 4.1.59.
2002014	SNMP dialup username.
2002015	SNMP dialup phone number.
2002016	SNMP scanner.
2002017	SNMP passwd.
2002018	SNMP community long.
2002019	SNMP echo bounce. Обнаружен пакет UDP путешествующий между портами SNMP и ECHO. Техника, которая иногда используется, заключается в том, что пакеты SNMP посылаются службе ECHO промежуточной системы. IP-адрес отправителя фальсифицируется так, чтобы ECHO посылалось службе SNMP атакуемой системы. Атакуемый объект доверяет промежуточной системе и поэтому принимает пакет.
2002020	SNMP HP Route Metachar.
2002101	rlogin -froot backdoor.
2002102	rlogin login name overflow.
2002103	rlogin password overflow.
2002104	rlogin TERM overflow.
2002105	Rlogin login name well known.
2002201	Melissa virus.
2002202	Papa virus.
2002203	PICTURE.EXE virus.
2002204	W97M.Marker.a virus.
2002205	ExploreZip worm.
2002206	Keystrokes monitored.
2002207	PrettyPark worm.
2002208	ILOVEYOU worm.
2002209	Worm extensions.
2002210	Worm address.
2002301	Duplicate IP address.
2002401	NNTP name overflow.
2002402	NNTP pipe seen.
2002403	NNTP Message-ID too long.
2002500	Suspicious URL.
2002501	bat URL type.
2002502	cmd URL type.
2002503	CGI aglimpse. Совершена попытка исполнить программу aglimpse, которая имеет известные уязвимости. Атакер сканирует web-сервер системы и ищет потенциальные уязвимости в секции web-сервера "dynamic content generation" (динамическая генерация содержимого). Эта утилита web-сервера исполняет отдельную программу для генерации web-страниц, когда пользователи осуществляют доступ к сайту. Существует сотни таких программ, которые содержат ошибки в сфере безопасности. В данном примере, хакер просматривает web-сервер и ищет одну из таких программ. Большая часть того, что вы читали в новостях о хакерских "штучках", является описанием слабостей таких программ и повреждений web-сайта. Особенно много информации можно найти о слабостях cgi-bin. Если скрипт виден внешнему миру, вам следует удалить его из данного каталога. Следует также удалить все динамическое содержимое, которое не является абсолютно необходимым для работы web-сайта. Выполните двойную проверку скриптов, которые вы действительно используете, на предмет наличия в них брешей уязвимости. Данная атака является стандартной, использующей метасимвольный CGI на PER. Программа PERL передает "поврежденный" ввод пользователя непосредственно в интерпретатору shell.
2002504	CGI AnyForm2. Совершена попытка исполнить программу anyform2, которая имеет известную уязвимость. Программа AnyForm cgi-bin содержит уязвимость, которая позволяет удаленному атакеру исполнять программы Web-сервера. Атакер сканирует web-сервер системы и ищет потенциальные уязвимости в секции web-сервера "dynamic content generation" (динамическая генерация содержимого). Эта утилита web-сервера исполняет отдельную программу для генерации web-страниц, когда пользователи осуществляют доступ к сайту. Существует сотни таких программ, которые содержат ошибки в сфере безопасности. В данном примере, хакер просматривает web-сервер и ищет одну из таких программ.
2002505	CGI bash. Совершена попытка исполнить скрипт bash, который в случае успеха, позволит хакеру получить доступ к серверу. Это программа shell, которая может исполнять произвольные операции на сервере. Если она была случайно помещена в удаленно доступный каталог, и, если вы обнаружили, что какие-то параметры системы стали доступны хакеру, считайте свою систему скомпрометированной. Вы должны немедленно удалить эту программу из данного каталога, проверить систему на наличие троянских коней и проконтролировать, не изменялась ли ее конфигурация.
2002506	CGI campas. Совершена попытка исполнить campas, которая имеет известную уязвимость. Это известный скрипт, поставляемый с оригинальными web-серверами NCSA. Он оказался весьма популярным среди хакеров (вместе с phf), но в настоящее время его важность незначительна. Эта точка уязвимости позволяет удаленному атакеру исполнять команды на ЭВМ Web-сервера, как если бы он работал на самой машине, где размещен httpd. Эта уязвимость разрешает доступ хакеру к файлам web-сервера. При определенных конфигурациях web-сервера возможно получение хакером административного доступа к ЭВМ.
2002507	CGI convert.bas.
2002508	CGI csh.
2002509	CGI faxsurvey.
2002510	CGI finger. Произведена попытка исполнить программу finger, который может позволить хакеру неавторизованный доступ к серверу. Атакер сканирует web-сервер системы и ищет потенциальные точки уязвимости в секции "dynamic content generation". Эта утилита web-сервера исполняет отдельную программу для генерации web-страниц, когда пользователь получает доступ к сайту. Существуют сотни таких программ, которые имею окна уязвимости. в данном примере, хакер просматривает web-сервер и ищет одну из таких уязвимых программ. Дополнительную информацию можно найти в cgi-bin exploits. Если этот скрипт виден внешнему миру, его следует удалить из данного каталога. Следует удалить также все динамические данные, которые совершенно необходимы для работы web-сайта.
2002511	CGI formmail.
2002512	CGI formmail.pl.
2002513	CGI glimpse. Попытка исполнения программы glimpse, которая известна своими уязвимостями. Эти уязвимости позволяют атакеру исполнять команды на ЭВМ Web-сервера во время работы процесса пользователя в httpd. В зависимости от конфигурации web-сервер, это может позволить атакеру получит root или административный доступ к ЭВМ. В любом случае, атакер сможет изменить содержимое web-сайта.
2002514	CGI guestbook.cgi.
2002515	CGI guestbook.pl.
2002516	CGI handler. Попытка исполнения CGI-хандлера, который обладает известными слабостями Эта CGI-программа является частью "Outbox Environment" в системах SGI IRIX. Программа может использоваться для выполнения любой команды на web-сервере. Для того, чтобы реализовать это, используйте программу Telnet следующим образом: telnet www.example.com 80 GET /cgi-bin/handler/useless_shit;cat /etc/passwd|?data=Download HTTP/1.0 Используйте символ TAB, чтобы ввести пробел в пределах команды.
2002517	CGI htmlscript.
2002518	CGI info2www.
2002519	CGI machineinfo.
2002520	CGI nph-test-cgi.
2002521	CGI perl. Произведена попытка исполнить perl-скрипт, который позволит хакеру неавторизованный доступ к серверу. Это программа shell, которая может выполнить произвольные операции на сервере. Если эта программа случайно помещена в удаленно доступный каталог, и, если выявлена модификация некоторого системного параметра, можете считать свою систему скомпрометированной. Вам следует немедленно удалить программу из ее каталога и поместить в более подходящее место, проверьте вашу систему на наличие троянских коней, а также проконтролируйте конфигурацию на предмет возможных модификаций.
2002522	CGI perl.exe. Произведена попытка исполнить perl.exe, которая позволит хакеру неавторизованный доступ к серверу. Это программа shell, которая может выполнить произвольные операции на сервере. Если эта программа случайно помещена в удаленно доступный каталог, и, если выявлена модификация некоторого системного параметра, можете считать свою систему скомпрометированной. Вам следует немедленно удалить программу из ее каталога и поместить в более подходящее место, проверьте вашу систему на наличие троянских коней, а также проконтролируйте конфигурацию на предмет возможных модификаций.
2002523	CGI pfdispaly.cgi.
2002524	CGI phf.
2002525	CGI rguest.exe.
2002526	CGI wguest.exe.
2002527	CGI rksh.
2002528	CGI sh.
2002529	CGI tcsh.
2002530	CGI test-cgi.tcl.
2002531	CGI test-cgi.
2002532	CGI view-source.
2002533	CGI webdist.cgi.
2002534	CGI webgais.
2002535	CGI websendmail.
2002536	CGI win-c-sample.exe.
2002537	CGI wwwboard.pl.
2002538	CGI uploader.exe.
2002539	CGI mlog.html.
2002540	CGI mylog.html.
2002541	CGI snork.bat.
2002542	CGI newdsn.exe.
2002543	FrontPage service.pwd.
2002544	.bash_history URL.
2002545	.url URL type.
2002546	.lnk URL type.
2002547	WebStore admin URL.
2002548	Shopping cart order URL.
2002549	Order Form V1.2 data URL.
2002550	Order Form data URL.
2002551	EZMall data URL.
2002552	QuikStore configuration URL.
2002553	SoftCart password URL.
2002554	Cold Fusion Sample URL.
2002555	favicon.ico bad format.
2002556	Site Server sample URL.
2002557	IIS sample URL.
2002558	IIS password change.
2002559	IIS malformed .HTR request.
2002560	IIS data service query.
2002561	.htaccess URL.
2002562	passwd.txt URL.
2002563	NT system backup URL.
2002564	CGI imagemap.exe.
2002565	adpassword.txt URL.
2002566	CGI whois suspicious field.
2002567	Cold Fusion cache URL.
2002568	IIS malformed HTW request.
2002569	CGI finger.cgi.
2002570	WebSpeed admin URL.
2002571	UBB suspicious posting.
2002572	SubSeven ICQ pager URL.
2002573	Oracle batch file URL.
2002574	sojourn.cgi argument contains %20.
2002575	Index Server null.htw exploit.
2002576	FrontPage extension backdoor URL. Прислан "подозрительный" URL. Библиотека dvwssr.dll, встроенная в расширения FrontPage 98 для IIS, включает в себя ключ шифрования "Netscape engineers are weenies!". Этот ключ может быть использован для маскирования имени запрошенного файла, который затем передается в качестве аргумента в dvwssr.dll URL. Любой, кто имеет привилегии доступа к web-серверу ЭВМ мишени может загрузить любую Web-страницу, включая файлы текстов программ ASP. Используя файл dvwsrr.dll можно также переполнить буфер. Успешная атака может позволить исполнение на сервере удаленной программы.
2002577	FrontPage htimage.exe URL.
2002578	InfoSearch CGI exploit.
2002579	Cart32 Clientlist URL.
2002580	Cart32 ChangeAdminPassword URL.
2002581	Listserv CGI exploit.
2002582	Calendar CGI exploit. Подозрительный URL. Конфигурационный параметр содержит мета-символы, которые вероятно означают, что атакер пытается использовать слабости в некоторых версиях CGI-скрипта. В случае успеха, он сможет выполнить произвольную команду на сервере.
2002583	Rockliffe CGI exploit.
2002584	RealServer Denial-of-service URL.
2002585	Java Admin Servlet backdoor URL. Административный модуль Java Web Server допускает компиляцию и исполнение программы Java server с помощью специального URL. Если атакеру удалось загрузить свой собственный Java-код на сервере, он может тогда скомпилировать и исполнить этот код и получить контроль над серверной системой.
2002586	DOS DoS URL.
2002587	Auction Weaver CGI exploit.
2002589	CGI jj exploit.
2002590	classifieds.cgi.
2002591	BNBSurvey survey.cgi.
2002592	YaBB exploit.
2002593	Webplus CGI exploit.
2002594	Squid cachemgr.cgi.
2002595	IIS system32 command.
2002596	Webevent admin.
2002597	Unify UploadServlet.
2002598	Thinking Arts directory traversal.
2002599	Lotus Domino directory traversal.
2002600	Commerce.cgi directory traversal.
2002601	CGI mailnews suspicious field.
2002602	FrontPage Publishing DoS.
2002603	way-board cgi file access.
2002604	roads cgi file access.
2002605	Hack-a-tack ICQ pager URL.
2002606	Bionet ICQ pager URL.
2002607	IIS .printer overflow.
2002608	ISAPI index extension overflow.
2002609	Y3K ICQ pager URL.
2002610	HTTP Pfdisplay Execute.
2002611	HTTP Pfdisplay Read.
2002701	SMB passwd file.
2002702	SMB sam file.
2002703	SMB winreg file.
2002704	SMB pwl file type.
2002705	SMB win.ini file.
2002706	Startup file access.
2002707	SMB autoexec.bat file access.
2002710	SMB RICHED20.DLL access.
2002801	MS rpc dump. Атакер пытается сканировать вашу систему для услуг RPC/DCOM. Возможно он ищет слабости в системе доступа. Была попытка загрузки списка всех услуг RCP/DCOM. Это специальная команда, которая может быть послана к "RPC End-Point Mapper" работающему с . Эта атака не направлена непосредственно на вторжение. Она является частью (разведывательного этапа) reconnaissance атаки. Команда 'epdump' попросит ЭВМ Windows перечислить все работающие сервисы. Хакер, получив эти данные, сможет эффективнее искать слабые места в вашей обороне. Если хакер найдет какие-то их этих услуг, он вероятно попытается воспользоваться ими. Например, существуют пути, посредством которых спамер может направить e-mail через Microsoft Exchange Servers. Путем выполнения 'epdump', спамер может выяснить, работает ли машина в качестве сервера. Если это так, спамер может затем заставить систему переадресовать SPAM своим "клиентам". Зафильтруйте порт 135 в firewall, как для UDP так и TCP.
2002802	MS share dump.
2002803	MS domain dump.
2002804	MS name lookup.
2002805	MS security ID lookup.
2002806	Malformed LSA request.
2002807	RFPoison attack.
2002808	LsaLookup Denial of Service.
2002901	PPTP malformed.
2002902	IGMP fragments.
2002903	SNTP malformed.
2002904	XDMCP gdm exploit.
2002905	VNC no authentication.
2002906	VCF attachment overflow.
2002907	SNTP overflow.
2002908	Quake Exploit.
2002911	RADIUS User Overflow.
2002912	RADIUS Pass Overflow.
2003001	HTTP port probe.
2003002	POP3 port probe.
2003003	SMTP port probe.
2003004	FTP port probe.
2003005	IMAP4 port probe.
2003006	TELNET port probe.
2003007	FINGER port probe.
2003008	RLOGIN port probe.
2003009	NetBIOS port probe.
2003010	NNTP port probe.
2003011	DNS TCP port robe.
2003012	PCANYWHERE port probe.
2003013	SQL port probe.
2003014	MSRPC TCP port probe.
2003015	XWINDOWS port probe. Возможно хакер просканировал вашу систему, чтобы проверить, доступно ли XWINDOWS. Иногда это делается в ходе подготовки будущей атаки, или иногда это делается с целью выяснения, уязвима ли ваша система.
2003016	RPC TCP port probe.
2003017	SOCKS port probe. Кто-то сканирует вашу систему, чтобы проверить, не работает ли там SOCKS. Это означает, что хакер хочет устроить переадресацию трафика через вашу систему на какой-то другой сетевой объект. Это может быть также chat-сервер, который пытается определить, не пробует ли кто-то использовать вашу систему для переадресации. SOCKS представляет собой систему, которая позволяет нескольким машинам работать через общее Интернет соединение. Многие приложения поддерживают SOCKS. Типичным продуктом является WinGate. WinGate инсталлируется на ЭВМ, которая имеет реальное Интернет соединение. Все другие машины в пределах данной области подключаются к Интернет через эту ЭВМ. Проблема с SOCKS и продуктами типа WinGate заключается в том, что они не делают различия между отправителем и получателем, что облегчает удаленным машинам из Интернет получить доступ к внутренним ЭВМ. Что важно, это может позволить хакеру получить доступ к другим машинам через вашу систему. При этом хакер маскирует свое истинное положение в сети. Атака против жертвы выглядит так, как если бы она была предпринята со стороны вашей машины. Этот вид атаки на первом этапе выглядит как сканирование. При использовании SOCKs систему следует конфигурировать так, чтобы заблокировать посторонний доступ. Хакер рассчитывает на вашу ошибку при конфигурации.
2003018	PPTP port probe.
2003019	IRC port probe.
2003020	IDENT port probe.
2003021	Linux conf port probe.
2003022	LPR port probe.
2003101	TCP trojan horse probe.
2003102	TCP port probe. Кто-то пытался получить доступ к вашей машине, но не смог. Это довольно распространенный вид атаки. Типовой хакер сканирует миллионы ЭВМ, не обольщайтесь вы не являетесь главным объектом интересов хакеров, но и расслабляться пожалуй не следует.
2003103	Netbus probe. Кто-то попрововал получить доступ к вашей ЭВМ с помощью "NetBus Trojan Horse" и потерпел неудачу. Хакер ищет ЭВМ, скомпрометированную посредством этой программы. Раз вы не скомпрометированы, хакер потерпел неудачу. Программа Trojan рассылается клиентам в надежде, что какой-то легкомысленный человек ее запустит. Задача такой программы похитить пароль, установить вирус, или переформатировать ваш диск. Специальную популярную группу образуют троянские кони, обеспечивающие удаленный доступ к вашей машине. Такие программы хакер пытается прислать по почте, через chat или новости, при этом хакер может не знать, где в Интернет находится ваша ЭВМ (он не знает, кто читает новости, да и по почте он рассылает эту гадость по тысячам адресов). Хакер знает только, кто является вашим провайдером, и вынужден сканировать всех клиентов данного ISP. При таком сканировании хакера устроит ситуация, когда вы получили данного троянского коня от другого атакера.
2003104	Proxy port probe. Атакер сканирует вашу систему с целью обнаружения прокси-сервера. Затем атакер может воспользоваться вашим прокси-сервером для анонимного просмотра Internet. В настоящее время сканирование TCP-портов 3128,8000 или 8080 рассматривается как обращение к прокси.
2003105	SubSeven port probe.
2003106	T0rn port probe.
2003201	SECURITY/SAM reg hack. Была предпринята попытка доступа к ключу registry под HKLM/SECURITY/SAM. Под этим ключом зарегистрированы имена и пароли пользователей. Хотя пароли зашифрованы, они могут быть проанализированы off-line и выяснены путем грубого перебора.
2003202	RUN reg hack. Была предпринята попытка записи в ключи registry, которые управляют программой при загрузке системы или когда в систему входит новый пользователь. Такими ключами являются HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Run HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunOnce HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunOnceEx HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunServices HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunServicesOnce HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunServicesEx Если имела места попытка записи в один из этих ключей, это может быть попыткой продвинуть Trojan Horse.
2003203	RDS reg hack. Была предпринята серьезная попытка скомпрометировать систему или легальная сетевая платформа осуществляет удаленное конфигурирование системы. Осуществлена попытка удаленной записи ключей registry HKLM\SOFTWARE\Microsoft\DataFactory\HandlerInfo или HKLM\SOFTWARE\Microsoft\Jet\3.5\Engines\SandboxMode. Эти ключи ограничивают удаленный доступ к определенным базам данных в системе Windows. Атакер может попытаться установить свои значения для этих объектов registry, так что неавторизованный удаленный доступ может быть осуществлен позднее через точку уязвимости RDO exploit. По умолчанию, эти ключи могут быть переписаны кем угодно. Разрешения должны быть изменены так, что только администратор мог их менять.
2003204	Index Server reg hack. Была предпринята попытка удаленного доступа к записям Index Server's registry. Сделана попытка доступа к ключу registry Remove remote access в HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\Winreg\AllowedPaths
2003205	NT RASMAN Privilege Escalation attempt. Была предпринята попытка удаленного доступа к троянскому коню RAS manager. Сделана попытка доступа к ключу registry HKLM\SYSTEM\CurrentControlSet\Services\RASMan, который удаленно изменяет программу путем изменения сервера, при следующем запуске ЭВМ, будет исполнена специфицированная программа.
2003206	LSA Secrets attempt. Была предпринята попытка удаленного доступа к "Local System Authority" через вызов registry. Атакер получает удаленный доступ к информации о секретных пароля хremotely. Эти пароли хранятся в зашифрованном виде в registry.
2003207	AeDebug reg hack.
2003208	IMail privilege escalation attempt.
2003209	SQL Exec Passwd. Была предпринята попытка сканирования записей SQLExecutive registry. Происходит подозрительное чтение записей registry из SQL-сервера. Иногда пароли записываются в registry, что делает систему уязвимой.
2003301	AOL Instant Messenger overflow.
2003302	AOL w00w00 attack.
2003401	SNMP port probe.
2003402	RPC UDP port probe.
2003403	NFS port probe.
2003404	TFTP port probe.
2003405	MSRPC UDP port probe.
2003406	UDP ECHO port probe.
2003407	CHARGEN port probe.
2003408	QOTD port probe.
2003409	DNS UDP port probe.
2003410	MSDNS port probe.
2003411	NFS-LOCKD port probe.
2003412	Norton Antivirus port probe.
2003501	UDP Trojan Horse probe.
2003502	UDP port probe.
2003601	FTP passwd file.
2003602	FTP sam file.
2003604	FTP pwl file type.
2003605	FTP win.ini file.
2003606	FTP Host File.
2003701	TFTP passwd file.
2003702	TFTP sam file.
2003704	TFTP pwl file type.
2003705	TFTP win.ini file.
2003706	TFTP Host File.
2003707	TFTP Alcatel files.
2003801	HTTP GET passwd file. Была предпринята подозрительная попытка доступа к файлу. Сделана попытка доступа к файлу passwd, который содержит зашифрованные Unix-пароли. Атакер может после этого использовать общедоступные программные средства для вскрытия паролей, содержащихся в этом файле.
2003802	HTTP GET sam file.
2003804	HTTP GET pwl file type.
2003806	HTTP GET AltaVista password.
2003901	HTTP POST passwd file.
2003902	HTTP POST sam file.
2003904	HTTP POST pwl file type.
2003905	HTTP POST win.ini file. Была предпринята попытка удаленного доступа к системному файлу WIN.INI посредством Web-формы. Эта попытка может быть сопряжена с намерением реконфигурировать систему, чтобы реконфигурированная система при последующем запуске загрузила троянского коня.
2004001	SOCKS connect. Кто-то подключился через вашу систему, используя протокол SOCKS. Это может быть хакер, который хочет переадресовать трафик через вашу систему на другие ЭВМ, а также сервер chat, пытающийся определить, не пробует ли кто-то проскочить через вашу систему чтобы работать анонимно на "халяву". SOCKS представляет собой систему, которая позволяет нескольким машинам работать через общее Интернет соединение. Многие приложения поддерживают SOCKS. Типичным продуктом является WinGate. WinGate инсталлируется на ЭВМ, которая имеет реальное Интернет соединение. Все другие машины в пределах данной области подключаются к Интернет через эту ЭВМ. Проблема с SOCKS и продуктами типа WinGate заключается в том, что они не делают различия между отправителем и получателем, что облегчает удаленным машинам из Интернет получить доступ ко внутренним ЭВМ. Что важно, это может позволить хакеру получить доступ к другим машинам через вашу систему. При этом хакер маскирует свое истинное положение в сети. Атака против жертвы выглядит так, как если бы она была предпринята со стороны вашей машины. Этот вид атаки на первом этапе выглядит как сканирование. При использовании SOCKs систему следует конфигурировать так, чтобы заблокировать посторонний доступ. Хакер рассчитывает на вашу ошибку при конфигурации. Ваша внутренняя сеть должна использовать IP-адреса, которые никогда не появляются в Internet. Такими адресами обычно являются "192.168.x.x", "172.16.x.x" или "10.x.x.x".
2004002	SOCKS over SOCKS. Кто-то подключился через вашу систему, используя протокол SOCKS. то может быть хакер, который хочет переадресовать трафик через вашу систему на другие ЭВМ. В этом случае, трафик оказывается инкапсулированным в SOCKS, это означает, что атакер вероятно намерен использовать вашу систему для переадресации к другой системе SOCKS. SOCKS представляет собой систему, которая позволяет нескольким машинам работать через общее Интернет соединение. Многие приложения поддерживают SOCKS. Типичным продуктом является WinGate. WinGate инсталлируется на ЭВМ, которая имеет реальное Интернет соединение. Все другие машины в пределах данной области подключаются к Интернет через эту ЭВМ. Проблема с SOCKS и продуктами типа WinGate заключается в том, что они не делают различия между отправителем и получателем, что облегчает удаленным машинам из Интернет получить доступ ко внутренним ЭВМ. Что важно, это может позволить хакеру получить доступ к другим машинам через вашу систему. При этом хакер маскирует свое истинное положение в сети. Атака против жертвы выглядит так, как если бы она была предпринята со стороны вашей машины.
2004101	Java contains Brown Orifice attack.
2004201	HTTP Cross site scripting.
2004301	DHCP Domain Metachar.
2004302	BOOTP File Overflow.
2004303	UPNP NOTIFY overflow.
2004401	SubSeven email.
2004402	Bionet email. Программа троянского коня Bionet имеет возможность посылать оповещения через e-mail, когда система, содержащая троянского коня, загружается. Это позволяет хакеру знать, что Bionet работает, и ваша система может быть компрометирована хакером. Судя по всему ваша система скомпрометирована. Вам следует использовать антивирусную программу, чтобы немедленно удалить троянского коня Bionet из вашей системы.
2004403	Y3K email.
2004501	HTTP GET contains xp_cmdshell. В качестве аргумента URL обнаружена строка xp_cmdshell; это обычно указывает, что предпринята попытка исполнить команду shell для атакера исполнять на сервере команды shell.
2004502	HTTP POST contains xp_cmdshell. В данных, передаваемых Web-сайту, обнаружена строка xp_cmdshell. Это обычно указывает, что предпринята попытка выполнить команду shell на SQL-сервере. Если SQL-сервер некорректно сконфигурирован, имеется возможность для атакера выполнять на сервере команды shell.
2004601	Code Red I.
2004602	Code Red II.
2004603	Code Red II+.
2009100	DNS crack successful.
2009201	ISS Scan.
2009202	CyberCop Scan.
2009203	Nessus Scan.
2009204	Satan Scan.
2009205	Saint Scan.
2009206	Cerebus Scan.
2009207	Retina Scan.
2010000-2010999	User-specified filename.
2011000-2011999	User-specified URL.
2012000-2012999	User-specified email recipient.
2013000-2013999	User-specified email pattern.
2014000-2014999	User-specified MIME-attached filename.
2015000-2015999	User-specified TCP probe port.
2016000-2016999	User-specified UDP probe port.
2017000-2017999	User-specified registry key.
2018000-2018999	User-specified TCP trojan response.
2019000-2019999	User-specified IRC channel name.
2020000-2020999	User-specified Java pattern.
2900001	Application Terminated.
2900002	Application Added.
2900003	Application Communication Blocked.
Config	Configuration parameters.

Обмен аутентификации

Рисунок .5. Обмен аутентификации

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

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

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

Компонент отклик аутентификации, который содержит отклик на вызов, сформированный получателем компонента запроса аутентификации.

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

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

2.3. Обзор базового уровня IOTP
Здесь описываются операции, которые образуют основу IOTP. Главными факторами, определяющими реализацию IOTP, являются роли, которые поддерживает реализованное решение. Роли в пределах IOTP более детально описаны в разделе 2.1. Базовыми ролями являются: продавец, покупатель, кассир, агент доставки и агент обслуживания покупателя.
Существует три типа Кассиров:

принимающие платеж как часть сделки или совершающие выплату, как возврат платежа;

принимающие средства как часть депозитной операции;

выдающие средства при отмене сделки.

Ниже приведенная таблица определяет для каждой роли операции IOTP и торговые блоки, которые должны поддерживаться для каждой роли.

Продавцы
	Склад	Пла-тиль-щик	Получа-тель платежа	Покупатель	Кассир	Агент доставки
Транзакции
Покупка	Нужно			Нужно
Продавцы
	Store	Пла-тиль-щик	Получа-тель платежа	Покупатель	Кассир	Агент доставки
Возврат средств	Нужно			b) Зависит
Аутентификация	Можно	Нужна	Можно	b) Зависит
Обмен ценностями	Можно			Нужно
Отзыв		Нужно		b) Зависит
Депозит			Нужно	b) Зависит
Запрос данных	Нужно	Нужно	Нужно	Можно	Нужно	Нужно
Ping	Нужно	Нужно	Нужно	Можно	Нужно	Нужно
Торговые блоки
TPO	Нужно	Нужно	Нужно	Нужно
Выбор TPO	Нужно	Нужно	Нужно	Нужно
Запрос Auth	a) Зависит		a) Зависит	a) Зависит
Отклик Auth	a) Зависит		a) Зависит	a) Зависит
Отклик предложения	Нужно	Нужно	Нужно	Нужно
Запрос платежа				Нужно	Нужно
Платежный обмен				Нужно	Нужно
Платежный отклик				Нужно	Нужно
Запрос доставки				Нужно		Нужно
Отклик доставки				Нужно		Нужно
Продавцы
	Склад	Пла-тильщик	Получа-тель	Покупатель	Кассир	Агент доставки
Запрос данных	Нужно	Нужно	Нужно	Нужно	Нужно	Нужно
Отклик данных	Нужно	Нужно	Нужно	Нужно	Нужно	Нужно
Запрос Ping	Нужно	Нужно	Нужно	Нужно	Нужно	Нужно
Отклик Ping	Нужно	Нужно	Нужно	Нужно	Нужно	Нужно
Подпись	Нужно	Нужно	Нужно	Ограничено	Нужно	Нужно
Ошибка	Нужно	Нужно	Нужно	Нужно	Нужно	Нужно

В выше приведенной таблице:

"Нужно" означает, что торговая роль должна поддерживать операцию или торговый блок.

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

"Зависит" означает, что программная реализация операции или торгового блока зависит от одного из следующих условий:

	- Поддерживаются базовые операции аутентификации IOTP;
	- Если требуется для данного метода платежа, как это определено в его сопровождающем документе IOTP.

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

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

Обмен для предложения, независимого от вида платежа

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

Заметим, что документальный обмен предложения, независимого от видов платежа происходит, когда продавец предлагает покупателю лишь один вид платежа, протокол и вид валюты. Это может произойти и при нескольких предлагаемых видах платежа, если имеется один Кассир и все виды платежа используют один и тот же набор протоколов. Заметим, что блоки TPO и отклика Offer могут быть посланы в одном IOTP-сообщении (смотри документальный обмен предложения, зависимого от вида платежа), даже если блок отклика Offer не изменяется. Однако это увеличивает число сообщений в транзакции и следовательно может увеличить время отклика.
Приложения, поддерживающие торговую роль Покупателя, должны проверять наличие блока отклика Offer в первом сообщении IOTP с тем чтобы определить, является ли обмен зависимым от вида платежа.
Принципы обработки сообщений
Получив сообщение TPO и отклика Offer (смотри ниже), Покупатель может:

сформировать и послать следующее сообщение IOTP транзакции соответствующей торговой роли. Это зависит от разновидности транзакции.

индицировать отказ, послав Продавцу блок Cancel, содержащий компонент Status с StatusType = Offer, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.1) равным: ConsCancelled или Unspecified.

Если продавец поличает сообщение, содержащее блок Cancel, тогда Покупатель вероятно направится в сетевой узел CancelNetLocn, специфицированный в элементе торговой роли компонента Organisation для Продавца.
9.1.2.3. Сообщение TPO
Сообщение используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), в это сообщение входит блок опций торгового протокола (смотри раздел 8.1), который описан ниже.
Блок TPO (TRADING PROTOCOL OPTIONS)
Блок опций торгового протокола (смотри раздел 8.1) должен содержать следующие торговые компоненты:

Один компонент протокольных опций, который определяет опции, относящиеся ко всей транзакции.
Смотри раздел 7.1.

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

Компоненты Organisation (смотри раздел 7.6), со следующими ролями:

	- Продавец, который сделал предложение
	- Покупатель, который осуществляет транзакцию
	- Кассир. "ID" компонента организщации-кассира содержится в атрибуте PhOrgRef компонента платежа (Payment).

Если транзакция IOTP включает доставку, тогда блок TPO должен содержать:

Компоненты Organisation со следующими ролями:

	- Агент доставки (DeliveryHandler), который осуществляет доставку товаров или услуг;
	- DelivTo т.e. лицо или организация, куда нужно выполнить доставку.

Блоки подписи и состояния аутентификации

Если за документальным обменом Offer следует обмен аутентификации, тогда сообщение TPO может также содержать:

блок состояния аутентификации (смотри раздел 8.6) и

опционный блок Signature (состояния аутентификации).

Для получения подробностей смотри раздел 9.1.1.4 (сообщение о состоянии аутентификации).

9.1.2.4. Сообщение IOTP выбора TPO

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

Блок выбора TPO (смотри раздел 8.2) содержит:

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

9.1.2.5. Сообщение отклик на предложение IOTP

Сообщение отклика Offer используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение состоит из:

блока отклика Offer (смотри раздел 8.1) aиnd

опционного блока подписи (смотри раздел 8.16).

Блок отклика предложения (блок отклика OFFER)


Блок отклика Offer (смотри раздел 8.3) содержит следующие компоненты:

один компонент Status (смотри раздел 7.16), который индицирует состояние отклика Offer. Атрибут ProcessState должен быть равен CompletedOk;

один компонент Order (смотри раздел 7.5), который содержит детали о товарах и услугах, которые покупаются, или о финансовых операциях, которые имеют место;

один или более компонентов (смотри раздел 7.9) для каждого платежа, которы надлежит произвести;

нуль или один компонент Delivery (смотри раздел 7.13), содержащий детали доставки, которую надлежит осуществить, если транзакция предполагает доставку;

нуль или более компонентов данных о торговой роли (смотри раздел 7.17), если это затребовано Продавцом.

Блок подписи (отклик предложения)

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

Если отклик Offer снабжен цифровой подписью, тогда должен быть включен блок Signature, который содержит компонент подписи (смотри раздел 7.19) с элементами дайджестов для следующих XML-элементов:

блок ссылок транзакции (смотри раздел 3.3) для сообщения, которое содержит информацию, описывающую сообщение и IOTP-транзакцию;

Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию;

Следующие компоненты блока TPO:

	- компонент опций протокола и
	- компонент списка видов платежей;
	- компоненты всех организаций.

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

	- компонент заказа;
	- все платежные компоненты;
	- компонент Delivery, если имеется;
	- любые компоненты данных о торговых ролях.

9.1.2.6. Сообщение TPO и отклика Offer

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

блок опций торгового протокола (TPO) (смотри раздел 8.1);

блок отклика Offer (смотри раздел 8.1) и

опционный блок Signature (смотри раздел 8.16).

Блок TPO (TRADING PROTOCOL OPTIONS)

Это тот же самый блок опций торгового протокола, что описан в IOTP-сообщении TPO (смотри раздел 9.1.2.3).

Блок отклика OFFER

Это тот же самый блок отклика Offer, что и в сообщении отклика Offer (смотри раздел 9.1.2.5).

Если до документального обмена Offer имел место обмен аутентификации, тогда сообщение TPO и отклика Offer может содержать (смотри раздел 8.6).

Блок подписи тот же самый блок Signature, что и в сообщении отклика Offer (смотри раздел 9.1.2.5), со следующими добавлениями:

если документальный обмен Offer является зависимым от вида платежа, тогда компонент Signature в блоке подписи дополнительно имеет элемент дайждеста для компонента выбора вида платежа, содержащегося в блоке выбора TPO;

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

9.1.3. Обмен документами при платеже

Документальный обмен платежа является непосредственной реализацией последней части платежного обмена (смотри раздел 2.2.2) после того как вид платежа выбран покупателем. Платежный обмен состоит из:

Покупатель формирует платежный запрос, используя информацию из предыдущего IOTP-сообщения, и посылает его кассиру;

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

Кассир посылает сообщение платежного отклика покупателю, где содержится платежная расписка.

IOTP-сообщения, которые используются при платежном обмене показаны на Рисунок .21.

1.	Покупатель формирует блок платежного запроса, если необходимо, инкапсулирует в него сообщение платежного протокола, и посылает кассиру, снабжая при необходимости цифровой подписью
C a P	Запрос платежа. IotpMsg: блоки Trans Ref; подписи (опционный); платежного запроса
2.	Кассир обрабатывает блок платежного запроса, проверяет подпись, если таковая имеется, и начинает обмен с покупателем сообщениями (вложенными в блок платежного обмена) согласно платежному протоколу
C « P	Платежный обмен. IotpMsg: блоки Trans Ref; Pay Exchange
3.	Покупатель и кассир продолжают обмен платежными блоками, пока платеж не будет осуществлен и кассир не сформирует платежную расписку (которая опционно может быть снабщена цифровой подписью) и не пошлет ее покупателю. Эта операция завершает платежный обмен.
C ? P	Платежный отклик. IotpMsg: блоки Trans Ref; Signature (опционный); платежного отклика
4.	Покупатель проверяет, все ли в порядке с платежным откликом. Опционно могут регистрироваться все операции IOTP. После этого покупатель может остановиться или послать очередное сообщение IOTP (снабдив его, если требуется, подписью) соответствующей торговой роли

Обмен документами при доставке

Рисунок .22. Обмен документами при доставке

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

сформировать и послать покупателю сообщение-отклик доставки или

индицировать сбой путем посылки покупателю блока Cancel, содержащего компонент Status с StatusType = Delivery, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равными: DelivCanceled или Unspecified.

Получив сообщение-отклик доставки, покупатель может считать, что транзакция завершена.
Если покупатель получает сообщение, содержащее блок Cancel, информация, содержащаяся в сообщении должна быть доведена до сведения покупателя и дальнейшая работа прервана.
9.1.4.2. Сообщение запроса доставки IOTP
Сообщение запроса доставки IOTP состоит из:

блок запроса доставки и

опционный блок подписи

Блок запроса доставки (смотри раздел 8.10) содержит:

следующие компоненты копируются из блока отклика Offer:

	- компонент Status (смотри раздел 7.16)
	- компонент Order (смотри раздел 7.5)
	- компонент Organisation (смотри раздел 7.6) с ролями: Продавец, Агент доставки и DeliverTo
	-компонент Delivery (смотри раздел 7.13)

следующий компонент из блока платежного отклика:

компонент Status (смотри раздел 7.16).

нуль или более компонентовданных о торговых ролях (смотри раздел 7.17).

Блок подписи (запрос доставки)
Если предыдущиц документальный обмен Offer содержит подпись отклика Offer илт платежный обмен содержит подпись платежного отклика, тогда тогда они должны быть скопированы в блок подписи.
9.1.4.3. Сообщение-отклик доставки
Сообщение-отклик доставки содержит блок отклика доставки и опционно блок подписи.
Блок отклика доставки содержит:

один компонент накладной (Delivery Note) (смотри раздел 7.15), который содержит инструкции по доставке товаров или услуг.

Блок подписи (отклик доставки)
Блок подписи должен содержать один компонент подписи, который содержит элементы дайджеста, которые относятся к:

Id-компоненту транзакции (смотри раздел 3.3.1) сообщения, которое содержит подпись отклика Delivery;

блок ссылок транзакции (смотри раздел 3.3) сообщения, которое содержит подпись отклика доставки;

компонент данных покупателя, содержащийся в блоке запроса доставки покупателя;

компоненты подписи, содержащиесчя в блоке запроса доставки (если имеется);

компонент Status;

компонент накладной (Delivery Note)

9.1.5. Обмен документами в процессе платежа и доставки

Документальный обмен платежа и доставки представляет собой комбинацию последней части торгового обмена платежа (смотри раздел 2.2.2) и обмена доставки (смотри раздел 2.2.3). Он состоит из:

Запрос покупателя начинается с формирования сообщения-запроса платежа, где используется информация предыдущего IOTP-сообщения транзакции. Далее этот запрос направляется кассиру;

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

Кассир посылает покупателю в одном сообщении IOTP:

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

IOTP-сообщения, которые вовлечены в этот процесс, показаны на Рисунок .23.

1.	Покупатель генерирует блок платежного запроса, в который, если требуется, вкладывается сообщение платежного протокола, и посылает его кассиру, снабжая опционно цифровой подписью
C a P	Платежный запрос. IotpMsg: блоки Trans Ref; подписи; платежного запроса
2.	Кассир обрабатывает блок платежного запроса, проверяет опционную подпись и начинает обмен с покупателем в рамках платежного протокола (вкладывая эти сообщения в блоки платежного обмена)
C « P	Платежный обмен. IotpMsg: блоки Trans Ref; платежного обмена
3.	Покупатель и кассир обмениваются блоками платежного обмена до тех пор пока платежный протокол не завершит свою работу. Кассир формирует компонент платежной расписки, помещает его в блок платежного отклика, опционно формирует компонент подписи, который укладывается в блок Signature, затем использует информацию из блока отклика предложения, чтобы сформировать блок отклика отклика доставки и посылает его покупателю.
C ? P	Отклики платежа и доставки. IotpMsg: блоки Trans Ref; подписи; платежного отклика; отклика доставки
4.	Покупатель проверяет блоки платежного отклика и отклика доставки. Опционно он может вести запись всех транзакций. Здесь покупатель может остановиться или сформировать очередное сообщение и послать его соотвествующе торговой роли.

Обмен доставки

Рисунок .4. Обмен доставки

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

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

Компоненты организации содержат информацию об адресе доставки и ролях агента доставки и продавца:

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

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

Компонент доставки содержит информацию о том, как будет осуществлена доставка, например по почте или с помощью e-mail.

Компонент подписи предложения-отклика (Offer Response), если присутствует, электронным образом подписывает все перечисленные выше компоненты, обеспечивая их целостность.

Компонент подпись платежной расписки (Payment Receipt) предоставляет подтверждение платежа, с помощью электронной подписи компонента платежной расписки и предложения. Это используется агентом доставки для проверки того, что доставка авторизована.

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

Компонент подпись отклика доставки (Delivery Response), если присутствует, предоставляет подтверждение результатов доставки путем электронной подписи накладной (Delivery Note) и подписей любого отклика-предложения или отклика платежа, которые получил агент доставки.

2.2.4.
Аутентификационный обмен

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

В аутентификационный обмен вовлечены:

Аутентификатор – организация, запрашивающая аутентификацию и

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

> Это проиллюстрировано на диаграмме ниже.

1.	Первая организация, например покупатель, осуществляет действие (например, нажимает на клавишу на HTML-странице), которое требует, чтобы организация была аутентифицирована.
1 a 2	Запрос аутентификации (за пределами действия IOTP)
2.	Вторая организация генерирует данные вызова и список алгоритмов, которые могут быть использованы для аутентификации и/или запрос данных об организации, после чего посылает все это первой организации.
1 ? 2	Запрос аутентификации. Компоненты: запрос аутентификации, запрос информации о торговых ролях.
3.	Первая организация опционно проверяет любую подпись, связанную с запросом аутентификации, после чего использует специфицированный алгоритм аутентификации, чтобы сформировать отклик аутентификации, который посылается второй организации вместе с запрошенной информацией об организации.
1 a 2	Отклик аутентификации. Компонент: отклик аутентификации, организации
4.	Отклик аутентификации проверяется согласно данным вызова для того чтобы выяснить является ли первая организация той, за которую себя выдает, результат записанный в компонент статус посылается первой организации.
1 ? 2	Статус аутентификации. Компонент: Статус
5.	Первая организация опционно проверяет результаты, записанные в cтатус, и все соответствующие подписи, после чего предпринимает некоторые действия или останавливает процедуру.

Обмен платежными документами

Рисунок .21. Обмен платежными документами

9.1.3.1. Принципы обработки сообщений Получив сообщение платежного запроса, кассир должен проверить, авторизован ли данный платеж (смотри раздел 6). Он может затем:

сформировать и послать сообщение платежного обмена покупателю, если этого требует платежный протокол или

сформировать и послать сообщение платежного отклика, если протокольный платежный обмен завершен или

индицировать сбой, послав покупателю блок Cancel, содержащий компонент Status с атрибутом StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равным: BrandNotSupp, CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument или Unspecified.

Получив платежное ообщение, Покупатель может:

сформировать и послать платежное сообщение Кассиру или

индицировать сбой, послав кассиру блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.2) равным: ConsCancelled или Unspecified.

Получив платежное ообщение, кассир может:

сформировать и послать платежное сообщение покупателю, если этого требует платежный протокол или

сформировать и послать сообщение платежного отклика, если протокольный платежный обмен завершен или

индицировать сбой, послав Покупателю блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодами CompletionCode (смотри раздел 7.16.2) равными: PaymtCancelled или Unspecified.

Получив платежное ообщение-отклик, Покупатель может:

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

остановиться, так как транзакция завершена или

индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.1) равным: ConsCancelled или Unspecified.

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

Если кассир получает сообщение, содержащее блок Cancel, тогда покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для кассира, здесь он сможет предпринять некоторые дальнейшие действия.

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

9.1.3.2. Сообщение платежного запроса

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение может содержать:

блок платежного запроса и

опционный блок подписи

Блок платежного запроса (смотри раздел 8.7) состоит из:

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

	- компонент Status
	- компонент Payment для выполняемого платежа

следующих компонентов блока TPO:

	- компоненты Organisation с ролями Продавец и Кассир, которые были пересланы в блоке платежного запроса;
	- компонент списка видов платежа, т.e. список видов платежа, указанный в атрибуте BrandListRef компонента Payment;

одного компонента выбора вида платежа, т.e. компонента выбора вида платежа, где атрибут BrandListRef указывает на список видов платежа. Этот компонент может быть:

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

опционного компонента платежной схемы (смотри раздел 7.10), если это требуется для используемого способа платежа (смотри, если нужно, приложение для платежных методов).

нуль или более компонентов данных о торговой роли (смотри раздел 7.17).

Заметим, что:

если в блоке отклика Offer имеется более одного компонента Payment, тогда вторым платежем являет тот, что записан в блоке отклика Offer и который содержит атрибут StartAfter (смотри раздел 7.9), указывающий на компонент Payment предыдущего платежа;

Кассир, который должен быть сюда включен, идентифицируется компонентом выбора платежа (смотри раздел 7.8). Объясненеи того как идентифицируется Кассир смотри в разделе 6.3.1;

компонент списка видов платежей определяется атрибутом BrandListRef компонента o Payment;

компонент выбора вида платежа берется из блока отклика Offer, где имеется атрибут BrandListRef (смотри раздел 3.5), который идентифицирует компонент списка видов платежей.

Блок подписи (запрос платежа)

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

9.1.3.3. Сообщение платежного обмена IOTP

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя блок платежного обмена.

Блок платежного обмена (смотри раздел 8.8) включает в себя:

один компонент платежной схемы (смотри раздел 7.10), который содержит специфические данные метода платежа. Подробности по платежному методу смотри в приложении.

9.1.3.4. Платежное сообщение отклика

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя:

платежный блок отклика

опционный блок подписи

Платежный блок отклика (смотри раздел 8.9) включает в себя:

один компонент платежной расписки (смотри раздел 7.11), которая содержит специфические данные для платежной схемы, которые позволяют, если нужно, проконтролировать платеж;

один компонент платежной схемы (смотри раздел 7.10), который, если требуется, содержит специфические данные метода платежа. Подробности смотри в приложении;

опционный компонент накладной (Payment Note) (смотри раздел 7.12);

нуль или более компонентов данных о торговой роли (смотри раздел 7.17).

Блок подписи (платежный отклик)


Если предоставлена подписанная платежная расписка, что индицируется атрибутом SignedPayReceipt= True компонента Payment, тогда блок Signature должен содержать компонент Signature, который содержит элементы дайджеста следующих видов:

блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит первый вариант блока платежного отклика,

Id-компонент транзакции (смотри раздел 3.3.1) в блоке ссылок транзакции, который однозначно идентифицирует транзакцию,

компонент платежной расписки из блока платежного отклика,

компонент накладной (Payment Note) из блока платежного отклика,

другие компоненты, на которые ссылается атрибут PayReceiptNameRefs (если имеется) компонента платежной расписки,

компонент Status из блока платежного отклика,

любой компонент данных о торговой роли в блоке платежного отклика и

все компоненты Signature, содержащиеся в блоке платежного запроса (если имеются).

9.1.4. Обмен документами при доставке

Документальный обмен доставки является непосредственной реализацией торгового обмена доставки (смотри раздел 2.2.3). Он состоит из следующих шагов:

Покупатель запрашивает доставку путем формирования сообщения запроса доставки. При этом используется информация предыдущего IOTP-сообщения транзакции и затем посылает его Агенту доставки;

Агент доставки посылает сообщение отклика доставки покупателю. Это сообщение содержит детали отклика агента на запрос и опционно цифровую подпись.

Схема обмена сообщениями представлена на Рисунок .22.

1.	Покупатель генерирует блок запроса доставки и посылает его агенту доставки, снабдив, если требуется, цифровой подписью
C a D	Запрос доставки. IotpMsg: блоки Trans Ref; подписи; запроса доставки
2.	Агент доставки проверяет компоненты Status и Order запроса доставки и опционно подпись, создает блок отклика доставки, посылает его покупателю.
C ? D	Отклик доставки. IotpMsg: блоки Trans Ref; подписи; отклика доставки
3.	Покупатель проверяет блок отклика доставки и опционный блок подпии. Опционно производит запись о транзакции на будущее.

Обработка ошибок IOTP

4. Обработка ошибок IOTP

IOTP создан как протокол запросов/откликов, где каждое сообщение состоит из нескольких торговых блоков, которые содержат некоторое. Существует несколько взаимосвязанных соображений при обработке ошибок, ретрансмиссий, дубликатов и тому подобное. Эти факторы приводят к тому, что IOTP вынужден обрабатывать поток сообщений не просто как последовательность запросов и откликов. Кроме того может встретится большое разнообразие ошибок в сообщениях, на транспортном уровне или в торговых блоках или компонентах. Датее будет рассмотрено, как IOTP обрабатывает ошибки, повторные попытки и дубликаты сообщений.
Могут произойти различные ошибки:

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

Глубина ошибки показывает, где произошла ошибка (при транспортировке, при составлении сообщения или на уровне блока/компонента)
4.1. Технические ошибки
К техническим ошибкам относятся ошибки, которые не зависят от значения сообщения. Это означает, что они могут влиять на любую попытку передачи. Обычно они обрабатываются стандартным образом с ограниченным числом опций для пользователя. Такие ошибки могут быть:
o повторная попытка передачи;
o аннулирование транзакции.
Когда связь работает достаточно хорошо, техническая ошибка индицируется компонентом Error (смотри раздел 7.21) в блоке Error (смотри раздел 8.17), посланным партнером, который детектировал ошибку в сообщении IOTP, партнеру, пославшему ошибочное сообщение.
Если связь слишком плохая, сообщение, которое было послано, может не достичь адресата. В этом случае может произойти таймаут.
Коды ошибок, соответствующие техническим ошибкам записываются в компоненте Error, где перечисляются различные технические ошибки, которые могут случиться.
4.2. Рабочие ошибки
Рабочие ошибки могут случиться, когда IOTP-сообщения "технически" вполне корректны.
Они связаны с определенным процессом, например, предложение, платеж, доставка или аутентификация, где каждый процесс имеет разный набор возможных рабочих ошибок.

Например, "Недостаточно средств" является сообщением об ошибке при платеже, но не имеет никакого значения для доставки, в то время как "Back ordered" возможное сообщение об ошибке доставки, но не имеет смысла для платежа. Рабочие ошибки индицируются компонентом Status (смотри раздел 7.16) "блока отклика" соответствующего типа, например, блока Payment Response или Delivery Response. Это допускает любой дополнительный отклик, связанный с информацией, которая необходима для пояснения возникшей ошибки.

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

4.3. Глубина ошибки

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

4.3.1. Транспортный уровень

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

Все ошибки транспортного уровня являются техническими и индицируются явно на транспортном уровне, как "No route to destination" из TCP/IP или через таймаут, когда не получено отклика на посланный запрос.

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

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


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

4.3.2. Уровень сообщения

Этот уровень ошибки указывает на фундаментальную техническую проблему с IOTP-сообщением в целом. Например, XML документ некорректно оформлен, сообщение имеет слишком большую длину для получателя, или обнаружена ошибка в блоке ссылок транзакции (смотри раздел 3.3).

Все ошибки уровня сообщений являются техническтими ошибками и индицируются компонентами Error (смотри раздел 7.21), послаными партером. Компонент Error включает в себя атрибут Severity (степень угрозы), который указывает, является ли ошибка предупреждениеим и может быть проигнорирована, TransientError и что повторная попытка может разрешить проблему или HardError, что говорит о срыве транзакции. Технические ошибки (смотри раздел 7.21.2; Коды ошибок), которые являются ошибками уровня сообщения, включают:

XML not well formed. Документ имеет не верный формат XML (смотри [XML])

XML not valid. Документ не вполне отвечает требованиям XML (смотри [XML])

Технические ошибки блочного уровня (смотри раздел 4.3.3) в блоке ссылок транзакции (смотри раздел 3.3) и блоке подписи. Следует проверить только эти блоки, если с XML все в порядке.

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

4.3.3. Уровень блоков


Ошибки блочного уровня указывают на проблему с блоком или одним из его компонентов в сообщении IOTP (помимо блоков ссылок транзакции или подписи). Сообщение передано корректно, структура всего сообщения, включая блоки ссылок транзакции и подписи, вполне разумна, но имеется ошибка, связанная с каким-то другим блоком. Ошибки блочного уровня могут быть:

техническими ошибками

рабочими ошибками

Технические ошибки далее делятся на:

Связанные с проверкой атрибутов блочного уровня и элементов.

Связанные с проверкой согласованности блоков и компонентов.

Переходные технические ошибки.

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

4.3.3.1. Проверки атрибутов блочного уровня и элементов

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

Проверки элемента и атрибута блочного уровня включают в себя:

проверку того, что значение каждого атрибута в каждом элементе блока согласуется с правилами спецификации IOTP;

проверку того, что содержимое каждого элемента согласуется с правилами спецификации IOTP;

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

4.3.3.2. Проверки согласованности компонентов и блоков

Проверки согласованности компонентов и блоков состоит из:

проверки того, что комбинации блоков и/или компонентов, присутствующих в сообщении IOTP, согласуются с правилами спецификации;

проверки взаимосогласованности атрибутов и содержимого элементов в блоках сообщения IOTP;

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

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


4.3.3.3. Переходные технические ошибки

Во время обработки блока могут произойти временные отказы, которые в принципе могут быть преодолены позднее повторной передачей исходного сообщения. В этом случае партнер информируется о переходной ошибке путем посылки компонента Error (смотри раздел 7.21) с атрибутом Severity равным TransientError и атрибутом MinRetrySecs равным некоторому значению, удобному для используемого транспортного механизма и/или платежного протокола (смотри соответствующие приложения транспортного и платежного протокола). Заметим, что переходные технические ошибки могут генерироваться любыми торговыми агентами, вовлеченными в транзакцию.

4.3.3.4. Рабочие ошибки блочного уровня

Если в процессе платежа или доставки происходит рабочая ошибка, тогда присылается соответствующий тип блока отклика, содержащий компонент Status (смотри раздел 7.16) с атрибутом ProcessState равным Failed и CompletionCode, указывающим на природу проблемы.

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

Преодоление переходных рабочих ошибок зависит от CompletionCode. Для понимания имеющихся возможностей смотри определение компонента Status. Заметим, что для рабочих ошибок не формируется компонент или блок Error.

4.4. Idempotency, последовательность обработки и поток сообщений

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


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

4.5. Последовательность обработки для роли сервера

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

o	Инициировать транзакцию (смотри раздел 4.5.1). Это могут быть:
	-	платеж, связанный с транзакцией;
	-	инфраструктурные транзакции.
o	Принять и обработать сообщение полученное от другой торговой роли (смотри раздел 4.5.2). Сюда относится:
	-	идентификация, если сообщение принадлежит транзакции, которая была запущена ранее;
	-	обработка сообщений-дубликатов;
	-	генерация переходных ошибок, если сервер, который обрабатывает входные сообщения перегружен;
	-	обработка сообщения, если оно лишено ошибок и авторизовано, и при благоприятном исходе, послать отклик отправителю сообщения.
o	Аннулировать текущую транзакцию, если поступил такой запрос (смотри раздел 4.5.3)
o	Повторно передать сообщение, если ожидается отклик, который не поступил за определенный период времени (смотри раздел 4.5.4).

4.5.1. Инициализация транзакций

Роли сервера могут инициировать большое число различных транзакций. В чатности:

o	Транзакцию информационного запроса (смотри раздел 9.2.1);
o	Транзакцию Ping (смотри раздел 9.2.2);
o	Транзакцию аутентификации (смотри раздел 9.1.6);
o	Транзакцию, сопряженную с платежем, такую как:
	-	Депозит (смотри раздел 9.1.7);
	-	Покупка (смотри раздел 9.1.8);
	-	Возврат денег (смотри раздел 9.1.9);
	-	Отзыв сделки (смотри раздел 9.1.10);
	-	Обмен ценностями (смотри раздел 9.1.11).

4.5.2.


Обработка входных сообщений

Обработка входных сообщений включает в себя:

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

4.5.2.1. Проверка структуры и идентификация сообщений

Крайне важно проверить, что сообщение имее корректную XML-форму и идентификатор транзакции (IotpTransID-атрибут компонента TransId) в сообщении IOTP может быть распознан, так как IotpTransId будет нужен при формировании отклика.

Если входное сообщение сформировано некорректно, тогда генерируется компонент Error с атрибутом Severity равным HardError и код ошибки XmlNotWellFrmd.

Если входное сообщение сформировано правильно, но IotpTransId не может быть идентифицировано, генерируется компонент Error с :

o	атрибутом Severity = HardError и кодом ошибки (ErrorCode) = AttMissing,
o	содержимым PackagedContent, включающим в себя "IotpTransId" потерянного атрибута.

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

4.5.2.2. Выявление и обработка дублированных сообщений

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

Рекомендуемым способом проверки идентичности сообщений является проверка равентства их [DOM-HASH].

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

Если обработка не завершилась, генерируется компонент Error с атрибутом Severity = TransientError и кодом ошибки = MsgBeingProc, чтобы указать, что сообщение обрабатывается и послать его обратно отправителю, с предложением повторной присылки поздее.


4.5.2.3. Обработка недублированных сообщений

Если установлено, что сообщение не является дубликатом ранее полученного, тогда оно обрабатывается. Процедура обработки включает в себя:

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

Этот подход к обработке дублированных входных сообщений означает, что если получены два совершенно идентичных сообщения, будут посланы два идентичнх отклика. Это применимо также к информационным запросам и транзакциям Ping, когда в действительности состояние транзакции или возможность обработки сервером может измениться. Если требуется текущее состояние транзакции или сервера, тогда используется транзакция с новым значением ID-атрибута компонента MsgId.

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

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

Проверка того, что транзакция не зафиксировала ошибку и не оказалась аннулированной.


Предполагается следующий контроль:

o	предыдущие посланные или полученные сообщения не содержат серьезных (Hard) ошибок;
o	транзакция не была анулирована покупателем или торговой ролью сервера.

Если это имеет место, сообщение игнорируется. Транзакция с серьезной ошибкой или аннулированная транзакция не может быть перезапущена.

Если с транзакцией все в порядке, производится поиск ошибок на уровне сообщения. Это включает в себя:

проверку формат XML;

проверку того, что все элементы, атрибуты и содержимое блока ссылок транзакции не содержат ошибок и соответствуют спецификации IOTP;

проверку цифровой подписи, которая в свою очередь предполагает:

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

Проверка ошибок уровня блоков включает:

о	проверку в пределах каждого блока (помимо блока ссылок транзакции) того что:
	- атрибуты, элементы и содержимое элементов корректно;
	- значения атрибутов, элементы и содержимого элементов не противоречат друг другу в пределах блока.
о	проверку того, что комбинации блоков корректны
o	проверку того, что значения атрибутов, элементы и содержимое элементов взаимосогласованы на межблочном уровне в пределах входного сообщения с блоками, полученными или отправленными ранее. Это включает проверку уместности данного блока для этого типа транзакции.

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

4.5.2.4. Проверка ошибок в последовательности блоков

Далее при объяснении поиска ошибок в последовательностях блоков выражение типа "относится к транзакции IOTP" следует интерпретировать как "содержится в сообщении IOTP, где TransRef Block включает в себя IotpTransId, который указывает на данную танзакцию". Так, например, "Если ошибка или аннулированный блок относится к транзакции IOTP, которая не распознана, тогда..." следует интерпретировать как "Если ошибка или аннулированный блок содержатся в сообщении IOTP, TransRefBlock включает в себя IotpTransId, который относится к транзакции IOTP, которая не распознана, тогда...”.


Ошибки в последовательности прихода блоков зависят от блока. Блоки, где требуется проверка последовательности:

Error и Cancel блоки. Если Error или Cancel блок относится к транзакции IOTP, которая не распознана, тогда это серьезная (Hard) ошибка. Чтобы избежать зацикливания, не следует посылать оповещения об ошибке, если получен Error или Cancel блок транзакции IOTP.

Блоки отклика и информационного запроса. Если блоки отклика и информационного запроса относятся к транзакции IOTP, которая не распознана, это серьезная (Hard) ошибка.

Блок запроса аутентификации. Если блок запроса аутентификации относятся к транзакции IOTP, которая распознана, это серьезная (Hard) ошибка.

Блок отклика аутентификации проверяется следующим образом:

	- Если блок отклика аутентификации не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае.
	- Если блок отклика аутентификации не относится к аутентификационному запросу, который был ранее послан, то это серьезная (Hard) ошибка, в противном случае.
	- Если блок отклика аутентификации получен в рамках IOTP-транзакции, до того как аутентификация успешно завершилась, то это серьезная (Hard) ошибка.
о	Блок состояния аутентификации проверяется следующим образом:
	- если блок состояния аутентификации не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае,
	- если блок состояния аутентификации не относится к аутентификационному отклику, который был перед эти послан, тогда это серьезная (Hard) ошибка, в противном случае,
	- если блок состояния аутентификации получен для той же самой транзакции раньне, то это предупреждение (а не ошибка).
o	Блок выбора TPO (только для продавца) прооверяется следующим образом:
	- если блок выбора TPO не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае,
	- если блок выбора TPO не относится к транзакции IOTP, где блок TPO и отклик предложения (в одном сообщении) были посланы ранее, то это серьезная (Hard) ошибка, в противном случае,
	- если блок выбора TPO относится к транзакции IOTP, где только блок TPO (т.e. без отклика на предложение) был послан ранее, то это серьезная (Hard) ошибка, в противном случае,
	- если блок выбора TPO для того же блока TPO получен ранее, то это серьезная (Hard) ошибка.
o	Блок запроса платежа (только для кассира) проверяется следующим способом:
	- если блок запроса платежа относится к транзакции IOTP, которая не распознана, тогда все в порядке, в противном случае
	- если блок запроса платежа относится к транзакции IOTP, которая не связана с платежом, то это серьезная (Hard) ошибка, в противном случае
	- если был предшествующий платеж, который не прошел с кодом завершения недопускющим восстановление, то это серьезная (Hard) ошибка, в противном случае
	- если предыдущий платеж еще в работе, то это серьезная (Hard) ошибка.
o	Блок платежного обмена (только для кассира) проверяется следжующим образом:
	- если блок платежного обмена не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае
	- если платежный обмен не относится к транзакции IOTP, где такой обмен уже был, то это серьезная ошибка (Hard).
o	Запрос доставки (только для агентов доставки). Если блок запроса доставки относится к транзакции IOTP, которая распознана сервероим, то это серьезная ошибка.

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

Описанная выше проверка последовательности аутентификационных откликов и платежных запросов поддерживает повторение запросов Покупателя, если предыдущая операция не прошла, например:

o потому что не получен корректный отклик (напр., пароль) на аутентификацию или

o не удалось произвести оплату, так как нехватает денег на кредитной карточке.

Обработка входного сообщения, лишенного ошибок

Если входное сообщение прошло предыдущие проверки, то оно должно быть обработано и послан, если требуется, отклик. Заметим, что:

Информационные запросы на транзакции Ping следует игнорировать;

Если входное сообщение содержит блок Error с переходной ошибкой, следует подождать необходимое время и затем повторно послать предыдущее сообщение, если не было получено отклика на сообщение, посланное ранее;

Если входное сообщение содержит компонент Error с HardError или блок Cancel, тогда последующая обработка транзакции должна быть остановлена. Это включает в себя блокировку отправки любых текущих сообщений или посылку откликов на любые новые приходящие недублированные сообщения;

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

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

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

4.5.3. Аннулирование транзакции

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


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

если IotpTransId транзакции, которую надо аннулировать, не распознан, или она завершена, то запрос не проходит, в противном случае,

если IotpTransId относится к транзакции Ping, то запрос не проходит, в противном случае,

определить, какой локументальный обмен нужно прервать, сформировать блок Cancel и послать его партнеру.

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

4.5.4. Повторная посылка сообщений

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

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

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

o	TimedOutRcvr, если транзакция может быть восстановлена позднее, или
o	TimedOutNoRcvr, если транзакция невосстановима.

4.6. Последовательность обработки для роли клиента

"Роль клиента" в IOTP является торговой ролью Покупателя.

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


В частности Покупатель должен быть способен:

o	Инициировать транзакции (смотри раздел 4.6.1). Среди них могут быть:
	- платеж, связанный с транзакцией
	- инфраструктурные транзакции.
o	Воспринять и обработать сообщение, полученное от другой торговой роли (смотри раздел 4.6.2). Сюда входит:
	- идентификация того, принадлежит ли сообщение транзакции, запущенной ранее;
	- обработка дублированных сообщений;
	- генерирование переходных ошибок, если сервер, который обрабатывет входное сообщение перегружен;
	- обработка сообщения, если оно не имеет ошибок и, если необходимо, посылка отклика партнеру по результатам обработки.
o	Аннулировать текущую транзакцию, если поступил соответствующий запрос, например от пользователя (смотри раздел 4.6.3).
o	Повторно передать сообщение, если ожидаемый отклик не пришел своевременно (смотри раздел 4.6.4).

4.6.1. Операции инициализации

Роль Покупателя может инициировать большое число различных транзакций. В частности:

o	Процедуру запроса (смотри раздел 9.2.1)
o	Транзакцию Ping (смотри раздел 9.2.2)
o	Процедуру аутентификации (смотри раздел 9.1.6)

4.6.2. Обработка входных сообщений

Обработка входных сообщений для роли покупателя происхотит также как и для IOTP-сервера (смотри раздел 4.5.2) за исключением проверки ошибок в последовательности блоков (для IOTP-сервера смотри раздел 4.5.2.4).

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

4.6.2.1. Поиск ошибки в последовательности блоков

Последовательность обработки блоков для роли покупателя та же, что и для IOTP-сервера (смотри раздел 4.5.2.4) за исключением того, что роль покупателя подставляется вместо роли сервера IOTP:

о	Блоки Error и Cancel,
o	Блоки отклика и информационного запроса,
o	Блоки запросов аутентификации, отклика и состояния.

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


Блоки, где важна последовательность проверки перечислены ниже:

o	Блок TPO проверяется следующим образом:
	- если входное сообщение содержит блок запроса аутентификации и блок отклика на предложение, то это серьезная (Hard) ошибка, в противном случае,
	- если входное сообщение содержит блок запроса аутентификации и статуса аутентификации, то это серьезная (Hard) ошибка, в противном случае,
	- если входное сообщение содержит блок запроса аутентификации и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,
	- если входное сообщение содержит блок состояния аутентификации и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,
	- если входное сообщение содержит блок состояния аутентификации, а блок состояния аутентификации послан до сообщения-отклика аутентификации, то это серьезная (Hard) ошибка,
	- если входное сообщение содержит блок отклика на предложение и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,
o	Блок отклика предложения проверяется следующим образом:
	- если блок отклика на предложение является частью брэнд-независимого обмена предложения (смотри раздел 9.1.2.2), тогда никакой проверки последовательности не нужно, так как это первое сообщение, в противном случае,
	- если блок отклика на предложение не является частью транзакции IOTP, которая распознана покупателем, то это серьезная (Hard) ошибка, в противном случае,
	- если блок отклика на предложение не относится к транзакции, где в последнем сообщении послан блок выбора TPO, то это серьезная (Hard) ошибка.
o	Блок платежного обмена проверяется следующим образом:
	- если блок платежного обмена не относится к транзакции IOTP, которая распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,
	- если платежный обмен не относится к транзакции IOTP, где только что послан блок платежного запроса или платежного обмена, то это серьезная (Hard) ошибка.
o	Блок платежного отклика проверяется следующим образом:
	- если блок платежного отклика не относится к транзакции IOTP, которая распознана системой Покупателя, то это серьезная (Hard) ошибка, в противном случае,
	- если блок платежного отклика не относится к транзакции IOTP, где только что послан блок платежного обмена или блок платежного запроса, то это серьезная (Hard) ошибка.
o	Блок отклика доставки проверяется следующим образом:
	- если блок отклика доставки не относится к транзакции IOTP, которая распознана системой Покупателя, то это серьезная (Hard) ошибка, в противном случае,
	- если блок отклика доставки не относится к транзакции IOTP, где только что послан блок запроса платежа или платежного обмена, то это серьезная (Hard) ошибка.

4.6.3.Аннулирование операции

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

4.6.4. Повторная передача сообщений

Ретрансмиссия сообщений осуществляется так же, как и в случае сервера IOTP (смотри раздел 4.5.4).

Определения типов данных протокола IOTP

13. Определения типов данных протокола IOTP

Этот раздел содержит XML DTD для IOTP.

( AuthReqBlk | AuthRespBlk | AuthStatusBlk | CancelBlk | DeliveryReqBlk |
DeliveryRespBlk | InquiryReqBlk | InquiryRespBlk | OfferRespBlk | PayExchBlk |
PayReqBlk | PayRespBlk | PingReqBlk | PingRespBlk | TpoBlk | TpoSelectionBlk
)* ) >





Version NMTOKEN #FIXED '1.0'IotpTransId CDATA #REQUIRED
IotpTransType CDATA #REQUIREDTransTimeStamp CDATA #REQUIRED>

RespIotpMsg NMTOKEN #IMPLIED	xml:lang NMTOKEN #REQUIRED
LangPrefList NMTOKENS #IMPLIED	CharSetPrefList NMTOKENS #IMPLIED

SenderTradingRoleRef NMTOKEN #IMPLIED

SoftwareId CDATA #REQUIRED

TimeStamp CDATA #IMPLIED>

xml:lang NMTOKEN #REQUIRED	RelationshipType NMTOKEN #REQUIRED
Relation CDATA #REQUIRED	RelnKeyWords NMTOKENS #IMPLIED>

Content NMTOKEN "PCDATA"

Transform (NONE|BASE64) "NONE">

xml:lang NMTOKEN #REQUIRED	ShortDesc CDATA #REQUIRED
SenderNetLocn CDATA #IMPLIED	SecureSenderNetLocn CDATA #IMPLIED

SuccessNetLocn CDATA #REQUIRED>



AuthenticationId CDATA #REQUIREDContentSoftwareId CDATA #IMPLIED>


AuthenticationId CDATA #REQUIREDSelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED>


TradingRoleList NMTOKENS #REQUIRED>


>

xml:lang NMTOKEN #REQUIRED	OrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIRED	OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED	ApplicableLaw CDATA #REQUIRED

ContentSoftwareId CDATA #IMPLIED>

xml:lang NMTOKEN #REQUIRED	OrgId CDATA #REQUIRED
LegalName CDATA #IMPLIED	ShortDesc CDATA #IMPLIED

LogoNetLocn CDATA #IMPLIED>

>

TradingRole NMTOKEN #REQUIRED	IotpMsgIdPrefix NMTOKEN #REQUIRED
CancelNetLocn CDATA #IMPLIED	ErrorNetLocn CDATA #IMPLIED

ErrorLogNetLocn CDATA #IMPLIED>

Tel CDATA #IMPLIED	Fax CDATA #IMPLIED
Email CDATA #IMPLIED	NetLocn CDATA #IMPLIED>

Title CDATA #IMPLIED	GivenName CDATA #IMPLIED
Initials CDATA #IMPLIED	FamilyName CDATA #IMPLIED>

AddressLine1 CDATA #IMPLIED	AddressLine2 CDATA #IMPLIED
CityOrTown CDATA #IMPLIED	StateOrRegion CDATA #IMPLIED
PostalCode CDATA #IMPLIED	Country CDATA #IMPLIED

LegalLocation (True | False) 'False' >

	ID #REQUIRED
xml:lang NMTOKEN #REQUIRED	ShortDesc CDATA #REQUIRED PayDirection

(Debit | Credit) #REQUIRE>

xml:lang NMTOKEN #IMPLIED	BrandId CDATA #REQUIRED
BrandName CDATA #REQUIRED	BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED	ProtocolAmountRefs IDREFS #REQUIRED

ContentSoftwareId CDATA #IMPLIED>

ProtocolBrandId CDATA #REQUIRED>

	ID #REQUIRED
PayProtocolRef IDREF #REQUIRED	CurrencyAmountRefs IDREFS #REQUIRED

ContentSoftwareId CDATA #IMPLIED>

	ID #REQUIRED
Amount CDATA #REQUIRED	CurrCodeType NMTOKEN 'ISO4217-A'

CurrCode CDATA #REQUIRED>

xml:lang NMTOKEN #IMPLIED	ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED	ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED	SecPayReqNetLocn CDATA #IMPLIED

ContentSoftwareId CDATA #IMPLIED >

BrandSelProtocolAmountInfo?,	BrandSelCurrencyAmountInfo?)>
	ID #REQUIRED
BrandListRef NMTOKEN #REQUIRED	BrandRef NMTOKEN #REQUIRED

ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED>

ContentSoftwareId CDATA #IMPLIED>

ContentSoftwareId CDATA #IMPLIED>

ContentSoftwareId CDATA #IMPLIED >

	ID #REQUIRED
OkFrom CDATA #REQUIRED	OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED	SignedPayReceipt (True | False) #REQUIRED

StartAfterRefs NMTOKENS #IMPLIED>

	ID #REQUIRED
PaymentRef NMTOKEN #IMPLIED	ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED	ContentSoftwareId CDATA #IMPLIED>

	PaymentRef NMTOKEN #REQUIRED
PayReceiptNameRefs NMTOKENS #IMPLIED	ContentSoftwareId CDATA #IMPLIED>

	ID #REQUIRED
xml:lang NMTOKEN #REQUIRED	DelivExch (True | False) #REQUIRED
DelivAndPayResp (True | False) #REQUIRED	ActionOrgRef NMTOKEN #IMPLIED>

	NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED	OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED	DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #IMPLIED	SecDelivReqNetLocn CDATA #IMPLIED

ContentSoftwareId CDATA #IMPLIED>


ConsumerDeliveryId CDATA #REQUIRED>

	ID #REQUIRED
xml:lang NMTOKEN #REQUIRED	DelivHandlerDelivId CDATA #IMPLIED

ContentSoftwareId CDATA #IMPLIED >

	ID #REQUIRED
xml:lang NMTOKEN #REQUIRED	StatusType NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIED	ProcessState (NotYetStarted | InProgress |
CompletedOk | Failed | ProcessError) #REQUIRED CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED	StatusDesc CDATA #IMPLIED >

	ID #REQUIRED
Type NMTOKEN #REQUIRED	ElRef NMTOKEN #IMPLIED

ProcessReference CDATA #IMPLIED >

	NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIRED	ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED	Severity (Warning|TransientError|HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED	SwVendorErrorRef CDATA #IMPLIED>

	NMTOKEN #REQUIRED
IotpMsgRef NMTOKEN #IMPLIED	BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED	ElementRef NMTOKEN #IMPLIED

AttName NMTOKEN #IMPLIED>

























Payment, PaySchemeData?, Org*, TradingRoleData*)>







PaymentNote?, TradingRoleData*) >


ConsumerDeliveryData?, TradingRoleData*) >














LastReceivedIotpMsgRef NMTOKEN #IMPLIED
LastSentIotpMsgRef NMTOKEN #IMPLIED>







PingStatusCode (Ok | Busy | Down) #REQUIRED
BR/P> xml:lang NMTOKEN #IMPLIEDPingStatusDesc CDATA #IMPLIED>


>














Digest+,
Attribute*,
OriginatorInfo,
RecipientInfo+ )>




>type (digest|signature) #IMPLIEDname NMTOKEN #REQUIRED>





>critical ( true | false ) #REQUIRED>





SignatureValueRef IDREF #IMPLIEDSignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED>








>





#REQUIRED>

Открытый торговый протокол Интернет–

4.6. 1 Открытый торговый протокол Интернет– IOTP версия 1.0

Перевод Семенова Ю.А. (ГНЦ ИТЭФ)

Мерзавцам этим только б воровать, Про то торговцы титулами знают, Но, кроме денег, им на все плевать. Джузеппе Джусти, "Шутки"

Открытый торговый протокол Интернет IOTP (Internet Open Trading Protocol; D. Burdett, RFC-2801, смотри также RFC-2935) создает базу коммерции через Интернет. Протокол не зависит от используемой платежной системы и т.д.. IOTP способен обрабатывать ситуации, когда продавец выступает в качестве покупателя, обеспечивает оформление и отслеживание доставки товаров и прохождения платежей, или совмещает некоторые или все перечисленные функции.

IOTP поддерживает:

Известные модели торговли

Новые модели торговли

Глобальную совместимость

1.1. Коммерция в Интернет

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

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

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

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

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

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

1.2. Преимущества IOTP

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

Виды платежей

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

Продавцы

Существует несколько преимуществ для торговцев:

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

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

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

новые торговцы смогут вступить в этот Интернет-рынок с новыми продуктами и услугами, используя новые возможности, предоставляемые IOTP.

Банки и финансовые организации


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

они смогут предоставить услуги IOTP для торговцев

они найдут новые возможности для реализации услуг, сопряженных с IOTP:

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

они имеют возможность построить отношения с новыми продавцами

Покупатели

Для покупателей также имеется несколько преимуществ:

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

>

имеется более удобный интерфейс для осуществления покупки

существуют возможности уладить их проблемы через продавца (а не через банк)

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

1.3. Основы IOTP

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

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

Схемы платежей которые поддерживает IOTP включают MasterCard Credit, Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, Proton и т.д..

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

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

Отношения элементов списка видов платежа

Рисунок .15. Отношения элементов списка видов платежа

Примеры списков видов платежа содержатся в главе 11.2. 7.7.1. Элемент Brand
Элемент Brand описывает вид платежа, который может быть использован при оплате покупки. Один или более таких элементов образуют компонент списка видов платежа, который имеет атрибут PayDirection, установленный равным Debit. Только один элемент вида платежа может содержаться в компоненте списка видов платежа (Brand List), который имеет атрибут PayDirection = Credit.

xml:lang NMTOKEN #IMPLIED BrandId CDATA #REQUIRED BrandName CDATA #REQUIRED BrandLogoNetLocn CDATA #REQUIRED BrandNarrative CDATA #IMPLIED ProtocolAmountRefs IDREFS #REQUIRED ContentSoftwareId CDATA #IMPLIED>
Атрибуты:

ID	Идентификатор элемента, относящийся потенциально к компоненту выбора вида платежа (Brand Selection), содержащегося в последнем сообщении платежного запроса, и однозначно идентифицирующий элемент Brand данной транзакции.
xml:lang	Определяет язык, используемый атрибутами и содержимым данного элемента. Смотри раздел 3.8.
BrandId	Содержит уникальный идентификатор для вида платежа. Он используется для установления соответствия со списком платежных инструментов, которыми располагает Покупатель, чтобы определить, может ли он обеспечить платеж данного вида.

Так как значения BrandId управляются процедурами IANA, допускается определение значений самим пользователем.

BrandName	Содержит название вида платежа, например MasterCard. Это описание вида платежа, которое отображается для Покупателя на понятном для него языке, заданном атрибутом xml:lang. Например, это может быть "American Airlines Advantage Visa". Заметим, что этот атрибут не используется для установления соответствия с инструментами платежа, которыми располагает Покупатель.
BrandLogoNetLocn	Сетевая позиция, которая может быть использована для загрузки логотипа организации. Смотри раздел “Получение логотипа” (раздел 10).

Содержимое этого атрибута должно соответствовать документу [RFC1738].

Cодержимое:

PackagedContent

Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протоколе и/ или виде платежа, которые может использовать платежный протокол. Содержимое этой информации определяется в приложении для платежных протоколов.

7.7.3. Элемент Protocol Amount

Элемент Protocol Amount связывает вид платежа с:

видом валюты и суммами в элементах Currency Amount (смотри раздел 7.7.4), которые могут использоваться с данным видом платежа, и

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

Его определение представлено ниже:


PayProtocolRef IDREF #REQUIREDCurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >

Атрибуты:

ID	идентификатор элемента, на который может ссылаться элемент Brand; или компонент выбора видов платежа, содержащийся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент Protocol Amount для данной транзакции IOTP.
PayProtocolRef	Содержит ссылку элемента (смотри раздел 3.5), которая указывает на элемент платежного протокола (смотри раздел 7.7.5), содержащийплатежный протокол и Кассира, которые могут использоваться для данного вида платежа.
CurrencyAmountRefs	Содержит список ссылок элемента (смотри раздел 3.5), который указывает на элемент Currency Amount (смотри раздел 7.7.4), описывающий вид валюты и сумму, которые могут использоваться для данного вида платежа.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протокольной сумме, которая может использоваться платежным протоколом. Содержимое этой информации определено в приложении для платежных протоколов.

Примеры элементов Protocol Amount приведены в секции 11.2.

7.7.4. Элемент валютной суммы


Элемент валютной суммы содержит в себе:

код валюты (и ее тип),

сумму.

Один или более таких элементов заключены в каждом компоненте списка видов платежа. Его определение приведено ниже:


>Amount CDATA #REQUIREDCurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED >

Атрибуты:

ID	Идентификатор элемента, (Brand Selection), содержащиеся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент Currency Amount данной транзакции IOTP.
Amount	Указывает сумму, которая должна быть заплачена. Например $245.35 будет выражено как "245.35". Заметим, что значения меньше наименьшей целой величины вполне допустима. Например одна десятая цента будет записана как "0.001".
CurrCodeType	Указывает CurrCode области. Этот атрибут включен с тем, чтобы была возможность поддержания нестандартных "валют" например “торговых марок” и т.д.. Атрибут может принимать значения:

ISO4217-A (по умолчанию) указывает код валюты с помощью трех буквенных символов, которые должны согласовываться с [ISO 4217]

IOTP указывает, что значения CurrCode управляются процедурой, описанной в разделе 12.

CurrCode

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

Так как значения CurrCodeType управляются процедурой, описанной в секции 12, допускается определение пользователем собственных значений CurrCodeType. Примеры элементов Currency Amount представлены в разделе 11.2.

7.7.5. Элемент платежного протокола

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

xml:lang NMTOKEN #IMPLIED	ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED	ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED	SecPayReqNetLocn CDATA #IMPLIED

ContentSoftwareId CDATA #IMPLIED>


Атрибуты:

ID	Идентификатор элемента, на который может ссылаться элемент Brand; или компонент выбора вида платежа (Brand Selection), содержащиеся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент PayProtocol данной транзакции IOTP.
xml:lang	Определяет язык, используемый атрибутами и содержимым данного элемента. Смотри раздел 3.8.
ProtocolId	Состоит из имени протокола и версии, например "SETv1.0".

Значения ProtocolId определены схемой/методом платежа владельцев в документе, который описывает, как инкапсулировать платежный протокол в IOTP.

ProtocolName	Описание платежного протокола и его версии на языке, идентифицированном атрибутом xml:lang. Например "Secure Electronic Transaction Version 1.0". Его целью является помочь, если требуется, в предоставлении информации об используемом платежном протоколе.
ActionOrgRef	Ссылка элемента (смотри раздел 3.5) на компонент Organisation для Кассира при данном платежном протоколе.
PayReqNetLocn	Сетевая позиция, указывающая куда следует послать платежный запрос в отсутствии гарантии безопасности при заданном протоколе.

Содержимое этого атрибута зависит от транспортного механизма (и должно быть согласованос документом [RFC1738].

SecPayReqNetLocn

Сетевая позиция, указывающая куда следует послать платежный запрос в условиях гарантии безопасности при заданном протоколе. Безопасный платеж предполагает для коммуникации с кассиром использование безопасного канала, такого как [SSL/TLS].

Содержимое этого атрибута должно согласовываться с регламентациями документа [RFC1738]. Смотри раздел 3.9.

ContentSoftwareIdСмотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протоколе, который используется платежным протоколом. Содержание этой информации определяется в приложении для платежных ппротоколов.

Примеры элементов платежного протокола содержатся в разделе 11.2.

7.8. Компонент выбора вида платежа


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

в сообщениях платежных запросов в транзакциях покупки и обмена ценностями для идентификации вида платежа, протокола и кассира;

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

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

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


BrandSelCurrencyAmountInfo?) >

BrandListRef NMTOKEN #REQUIRED

BrandRef NMTOKEN #REQUIRED

ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED >

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент выбора вида платежа транзакции.
BrandListRef	Ссылка элемента (смотри раздел 3.5) компонента списка видов платежа, из которого был выбран Brand.
BrandRef	Ссылка элемента Brand компонента списка видов платежа, который был выбран из списка и использован для платежа.
ProtocolAmountRef	Ссылка элемента для Protocol Amount в пределах компонента списка видов платежа, который использован при платеже.
CurrencyAmountRef	Ссылка элемента для Currency Amount в пределах компонента списка видов платежа, который использован при платеже.

Cодержимое:

BrandSelBrandInfo, BrandSelProtocolAmountInfo, Содержит любые дополнительные данные, которые могут быть необходимы при конкретном платеже или протоколе. Смотри разделы 7.8.1, 7.8.2, и 7.8.3.

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

атрибут BrandListRef должен содержать идентификатор компонента списка видов платежа транзакции IOTP;

на каждый компонент списка видов платежа в блоке опций торгового протокола (смотри раздел 8.1) должен ссылаться один и только один компонент выбора вида платежа.

BrandRef должен относиться к ID Brand, содержащегося в компоненте списка видов платежа, на который ссылается BrandListRef

ProtocolAmountRef должен относиться к одному ID элемента, содержащемуся в атрибуте ProtocolAmountRefs элемента Brand, идентифицированного BrandRef

CurrencyAmountRef должен относиться к одному ID элемента содержащемуся в атрибуте ProtocolAmountRefs элемента Protocol Amount, идентифицированного ProtocolAmountRef.

Пример компонента выбора вида платежа включен в раздел 11.2.


7.8.1. Информационный элемент выбора вида платежа

Информационный элемент выбора вида платежа cсодержит любую дополнительную информацию, которая может быть необходима для какого-то конкретного вида платежа. Смотри приложение IOTP для платежных методов, где описано применние этого элемента.




Атрибуты:

ContentSoftwareId

Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Элементы Packaged Content (смотри раздел 3.7), содержащие дополнительные данные, которые могут быть необходимы для конкретного вида платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.

7.8.2. Элемент Amount Info протокола выбора вида платежа

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


ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

ContentSoftwareId

Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Элементы Packaged Content (смотри раздел 3.7), которые могут содержать дополнительную информацию, необходимую для конкретного вида платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.

7.8.3. Информационный элемент валютной суммы выбора вида платежа (Brand Selection Currency Amount Info)

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



ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

ContentSoftwareId

Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Элементы Packaged Content (смотри раздел 3.7), которые содержат дополнительную информацию, относящуюся к виду платежа и валюты. Смотри приложение IOTP по платежным методам, где описано использование этого элемента.

7.9. Компонент платежа (Payment)

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

Временном интервале в пределах которого Кассир может начать платежную операцию;

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

следует ли предоставлять платежную расписку;

должен ли данному платежу предшествовать другой платеж.

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

OkFrom CDATA #REQUIRED	OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED	SignedPayReceipt (True | False) #REQUIRED

StartAfterRefs NMTOKENS #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно идентифицирует платежный компонент в транзакции IOTP.
OkFrom	Дата и время в формате [UTC], после которого кассир может воспринимать на обработку блок платежного запроса (смотри раздел 8.7), содержащий компонент платежа.
OkTo	Дата и время в формате [UTC], до которого Кассир может воспринимать на обработку блок платежного запроса, содержащий компонент платежа.
BrandListRef	Ссылка элемента (смотри раздел 3.5) компонента списка видов платежа (смотри раздел 7.7) в рамках торгового блока TPO транзакции IOTP. Список видов платежа идентифицирует альтернативные способы осуществления платежа.
SignedPayReceipt	Указывает, должен ли быть подписан блок платежного отклика (смотри раздел 8.9), сгенерированный Кассиром.
StartAfter	Содержит ссылки элемента (смотри раздел 3.5) других платежных компонентов, которые описывают платежи, которые должны быть проведены до того, как будет произведен данный платеж. Если атрибут StartAfter отсутствует, тогда никаких зависимостей нет и платеж может быть проведен немедленно.

7.10. Компонент платежной схемы

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

PaymentRef NMTOKEN #IMPLIED	ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED	ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент схемы оплаты транзакции IOTP.
PaymentRef	Ссылка элемента (смотри раздел 3.5) компонента платежа (смотри раздел 7.9), с которым связан компонент схемы платежа. Атрибут необходим, если только компонент схемы платежа не является частью запроса состояния транзакции (смотри раздел 9.2.1).
ConsumerPaymentId	Идентификатор, специфицированный Покупателем, который в случае возвращения Кассиром в другом компоненте схемы платежа (или другим способом) позволит Покупателю определить, о каком платеже идет речь.
PaymentHandlerPayId	Идентификатор, специфицированный Кассиром, который в случае возвращения Покупателем в другом компоненте схемы платежа (или другим способом) позволит Кассиру определить, о каком платеже идет речь. Атрибут необходим для каждого компонента схемы платежа, вне зависимости от того, что содержится в блоке платежного запроса.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Содержит протокольную информацию о схеме платежа в виде элементов Packaged Content (смотри раздел 3.7). Определение содержимого смотри в приложение по схемам платежа.

Заметим, что:

значения атрибута Name каждого элемента pakaged content определены в приложении для платежных протоколов;

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

7.11.


Компонент платежной расписки

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

сумму платежа и его валюту;

дату и время платежа;

внутренние числовые ссылки, которые идентифицируют платеж для платежной системы;

цифровые подписи, выработанные платежным механизмом и призванные позднее подтвердить, что платеж состоялся.

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

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

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

Определение компонента платежной расписки.

	ID #REQUIRED
PaymentRef NMTOKEN #REQUIRED	PayReceiptNameRefs NMTOKENS #IMPLIED

ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент платежной расписки транзакции IOTP.
PaymentRef	Содержит ссылку элемента (смотри раздел 3.5) на компонент платежа (смотри раздел 7.9), к которому относится данная расписка.
PayReceiptNameRefs	Опционно содержит список значений атрибутов Name элементов Packaged Content, которые образуют расписку. Элементы Packaged Content могут содержать:
о	компоненты данных платежной схемы, обмен которыми производится между Кассиром и Покупателем в процессе платежа и/или
o	сам компоент платежной расписки. Заметим, что:
o	каждый компонент схемы определяет в своем приложении имена элементов Packaged Content, которые должны быть перечислены в этом атрибуте (если они нужны).
о	Если компонент платежной схемы содержит элементы Packaged Content, с именами которые совпадают с именем в PayReceiptNameRefs, тогда на такие компоненты платежной схемы должны ссылаться дайджесты в компоненте подписи платежного отклика (если используется такая подпись).

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

ContentSoftwareId

Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Опционно содержит информацию платежной расписки (платежную схему) в виде элементов Packaged Content (смотри раздел 3.7). Определение его содержимого смотри в прилжении платежной схемы.

Заметим, что:

о	значения атрибута Name каждого элемента packaged content определены приложением платежного протокола;
о	значение Name должно быть уникальным для каждого платежа, как и для всех схем платежа или компонентов платежной расписки с идентичным значением атрибута PaymentRef.

Заметим, что должны присутствоать либо атрибут PayReceiptNameRefs, либо элемент PackagedContent или оба.

7.12. Компоент Payment Note

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

Информация, содержащаяся в компоненте Payment Note должна быть отображена или представлена каким-то иным способом покупателю. Для совместимости компонент Payment Note должен поддерживать как минимум содержимое типа "Plain Text", HTML и XML. Его определение представлено ниже.




Атрибуты:

ID	Идентификатор, который однозначно определяет компонент платежной расписки транзакции IOTP.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Содержит дополнительную, не связанную с платежом информацию, которую кассир хочет довести до сведения покупателя в виде одного или более элементов Packaged Content (смотри раздел 3.7).

7.13.


Компонент доставки

Компонент доставки содержит информацию, необходимую для доставки товаров или услуг. Его определение приведено ниже.

xml:lang NMTOKEN #REQUIRED	DelivExch (True | False) #REQUIRED
DelivAndPayResp (True | False) #REQUIRED	ActionOrgRef NMTOKEN #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент доставки транзакции.
xml:lang	Определяет язык, используемый атрибутами и дочерними элементами этого компонента, если только атрибут дочернего элемента xml:lang не перепишет это значение. Смотри раздел 3.8.
DelivExch	Индицирует факт наличия в транзакции сообщений, ассоциированных с обменом доставки. Корректные значения: о“Истинно” указывает на наличие обмена доставки. o“Ложно” указывает на отсутствие обмена доставки.

Если DelivExch = true, должен присутствовать элемент DeliveryData. Если DelivExch = false, он может отстутствовать.

DelivAndPayResp

Индицирует то, чтоблок отклика доставки (смотри раздел 8.11) и блок отклика плптежа (смотри раздел 8.9) находся в одном и том же сообщении IOTP. Корректные значения: o “Истинно” указывает, что оба блока находятся в одном и том же сообщении IOTP и o “Ложно” указывает, что каждый блок размещен в разных сообщениях IOTP.

Атрибут DelivAndPayResp не должен иметь значение “истинно”, если DelivExch = “ложно”.

На практике комбинирование блока отклика доставкии блока отклика платежа имеет смысл только в случае, когда Продавец, Кассир и Агент доставки принадлежат одной организации, так как:

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

ActionOrgRef

Ссылка элемента на компонент организации Агента доставки.

Cодержимое:

DeliveryData	Содержит подробности того, как будет осуществляться доставка. Смотри 7.13.1.
PackagedContent	Содержит данные "пользователя", определенные для продавца и необходимые агенту доставки в виде одного или нескольких элементов Packaged Content. Смотри раздел 3.7.

7.13.1. Элемент Delivery Data

Элемент DeliveryData содержит информацию о том, куда и как должны доставляться товары или услуги. Его определение представлено ниже.

	NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED	OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED	DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #REQUIRED	SecDelivReqNetLocn CDATA #REQUIRED

ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

xml:lang	Определяет язык, используемый атрибутами компонента. Смотри раздел 3.8.
OkFrom	Дата и время в формате [UTC] после которого Агент доставки может принять на обработку блок запроса доставки (смотри раздел 8.10).
OkTo	Дата и время в формате [UTC], до которого Агент доставки может принять на обработку блок запроса доставки.
DelivMethod	Индицирует метод, с помощью которого могут быть доставлены товары или предоставлены услуги. Корректными считаются значения: о Post. Товары будут доставлены по почте или курьером. o Web. Товары будут доставлены электронным образом в комоненте Delivery Note. o Email. Товары будут доставлены электронным образом через e-mail

Значения DelivMethod управляются процедурой, описанной в разделе 12, что допускает определение новых кодов пользователем.

DelivToRef	Ссылка элемента (смотри раздел 3.4) компонента Organisation транзакции IOTP, которая имеет роль DelivTo. Информация в этом блоке используется, чтобы определить, куда следует доставить покупку. Она должна быть совместимой с DelivMethod. В частности, если DelivMethod является: о Post, тогда здесь должен быть элемент почтового адреса, содержащий достаточно информации для доставки по почте, o Web, тогда не нужны никакие специфические требования. Информация будет послана на web-страницу Покупателя, o Email, тогда здесь должен быть элемент контактной информации с корректным адресом e-mail.
DelivReqNetLocn	Содержит сетевую позицию, куда должен быть послан небезопасный блок запроса доставки (смотри раздел 8.10), который содержит компонент доставки. Содержимое этого атрибута зависит от транспортного механизма и должно согласовываться с требованиями документа [RFC-1738].
SecDelivReqNetLocn	Содержит сетевую позицию, куда должен быть послан безопасный блок запроса доставки (смотри раздел 8.10), который содержит компонент доставки.

<


Безопасный запрос доставки предполагает использование безопасного канала, такого как [SSL/TLS] для того чтобы взаимодействовать с кассиром.

Содержимое этого атрибута зависит от транспортного механизма и должно соответствовать регламентациям документа [RFC1738]. Смотри также раздел 3.9.

ContentSoftwareId

Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Дополнительная информация о доставке в виде одного или несколько элементов Packaged Content (смотри раздел 3.7), предоставляемая агенту доставки продавцу.

7.14. Информационный компонент доставки Покупателя

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


ConsumerDeliveryId CDATA #REQUIRED>

Атрибуты:

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

7.15. Компонент Delivery Note

Компонент Delivery Note (накладная)содержит инструкции о доставке товаров или услу, или саму информацию о доставке. Это информация, которую частное лицо или организация, получающие накладную, могут использовать, когда осуществляется доставка.

Для совместимости компонент Delivery Note должен поддерживать Plain Text, HTML и XML. Его определение представлено ниже.

	xml:lang NMTOKEN #REQUIRED
DelivHandlerDelivId CDATA #IMPLIED	ContentSoftwareId CDATA #IMPLIED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент Delivery Note транзакции IOTP.
xml:lang	Определяет язык, используемый атрибутами или дочерними элементами в рамках данного компонента, если только его значение не будет переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.
DelivHandlerDelivId	Опционный идентификатор, специфицированный Агентом доставки, который в случае возвращения Покупателем в другом компоненте доставки или каким-либо другим способом, позволяет Агенту доставки определить, о какой доставке идет речь. Он необходим для любого компонента доставки, вне зависимости от того содержится ли от в блоке запроса доставки.

ContentSoftwareId

Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Содержит информацию декларации доставки (delivery note) в виде одного или нескольких элементов Packaged Content (смотри раздел 3.7).

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

7.16. Компонент Status

Компонент Status содержит информацию состояния бизнес-процесса (успех или неудача) (смотри раздел 4.2). Его определение приведено ниже.

	xml:lang NMTOKEN #REQUIRED
StatusType NMTOKEN #REQUIRED	ElRef NMTOKEN #IMPLIED

ProcessState (NotYetStarted | InProgress | CompletedOk | Failed | ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIEDStatusDesc CDATA #IMPLIED >

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент Status транзакции IOTP.
xml:lang	Определяет язык, используемый атрибутами в пределах компонента. Смотри раздел 3.8.
StatusType	Индицирует тип обмена документами, о котором сообщает компонент Status. Он может быть установлен в состояние предложение, платеж, доставка, аутентификация или “неопределено” (Undefined).

“Непределено” означает, что тип документального обмена не может быть идентифицирован. Это может быть вызвано ошибкой исходного входного обмена сообщениями. Значения StatusType управляется процедурой, описанной в секции 12 (IANA), и допускающей определение новых значений пользователем.

ElRef

Если StatusType не установлено равным Undefined (неопределено), тогда ElRef содержит ссылку элемента (смотри раздел 3.5) на компонент, для которого описан Status. Он может относиться к: о компоненту Order (смотри раздел 7.5), если StatusType = Offer, o компоненту Payment (смотри раздел 7.9), если StatusType = Payment, o компоненту Delivery (смотри раздел 7.13), если StatusType = Delivery; o компоненту запрос аутентификации (смотри раздел 7.2), если StatusType = Authentication.

ProcessState

Содержит код состояния (State Code), который индицирует текущее состояние исполняемого процесса. Допустимыми значениями ProcessState являются: о NotYetStarted. Получен блок Request, но процесс еще не начат; o InProgress. Обработка блока Request начата, но еще не завершена; o CompletedOk. Обработка блока Request успешно завершена; o Failed. Обработка блока Request не прошла из-за рабочей ошибки (Business Error) (смотри раздел 4.2) o ProcessError. Это значение применяется, только когда компонент Status используется в связис торговым блоком информационного запроса (смотри раздел 8.12). Оно указывает, что была техническая ошибка (смотри раздел 4.1) в блоке запроса, который обрабатывается, тди другая внутренняя ошибка обработки.

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

CompletionCode

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

CompletionCode может иметь до 14 символов.

ProcessReference

Этот опционный атрибут хранит ссылку для процесса, о состоянии которого сообщается. Он может содержать следующие значения: о когда StatusType = Offer, он должен содержать OrderIdentifier компонента Order; o когда StatusType = Payment, он должен содержать PaymentHandlerPayId компонентаданных о схеме платежа; o когда StatusType = Delivery, он должен содержать DelivHandlerDelivId компонента Delivery Note; o когда StatusType = Authentication, он должен содержать AuthenticationId компонента запроса аутентификации.

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

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

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

StatusDesc

Опционное текстовое описание текущего состояния процесса на языке, заданном атрибутом xml:lang.

7.16.1. Коды завершения предложения

Код завершения является единственно необходимым, если атрибут ProcessState = Failed (неудача). Ниже следующая таблица содержит допустимые значения CompletionCode, которые могут использоваться и индицировать, возможно ли восстановление процесса. Рекомендуется, чтобы там, где это необходимо для дальнейшего разъяснения, использовался атрибут StatusDesc.

Значение	Описание
AuthError	Ошибка аутентификации. Проверка отклика аутентификации не прошла.

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

ConsCancelled	Прервано покупателем (Consumer Cancelled). Покупатель по каким-то причинам решает прервать транзакцию. Это код является единственно верным в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.
MerchCancelled	Предложение аннулировано (Offer Cancelled). Продавец по каким-то причинам аннулирует свое предложение и прерывает транзакцию. Этот код является единственно верным в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.
Unspecified	Неспецифицированная ошибка. Возникла какая-то неизвестная проблема или ошибка, которая не соответствует ни однму из кодов CompletionCodes. Восстановление невозможно.
TimedOutRcvr	Восстановимый таймаут (Recoverable Time Out). Сообщения были посланы, а откликов не получено. Документальный обмен прерван таймаутом. Этот код допустим в случае информационного запроса транзакции.

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

TimedOutNoRcvr

Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были посланы повторно, а откликов не получено. Документальный обмен прерван таймаутом. Этот код допустим в случае информационного запроса транзакции. Восстановление невозможно.

7.16.2. Коды завершения платежа

CompletionCode необходим, если атрибут ProcessState = Failed. Ниже следующая таблица содержит допустимые значения CompletionCode, которые могут использоваться и индицировать, когда возможно восстановление. Рекомендуется, чтобы атрибут StatusDesc использовался индивидуальными платежными схемами для предоставления дальнейших пояснений, там где это уместно.

Значение	Описание
BrandNotSupp	Вид платежа не поддерживается Кассиром.

Ниже приведены опции восстановления.

CurrNotSupp

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

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

ConsCancelled	Отмена Покупателем (Consumer Cancelled). Покупатель по какой-либо причине решил аннулировать платеж. Этот код является единственно верным в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.
PaymtCancelled	Платеж аннулирован (Payment Cancelled). Кассир по каким-то причинам не хочет завершить платежную операцию и аннулирует транзакцию. Этот код является единственно верным в компоненте Status, содержащегося в блоках Cancel или информационного отклика. Опции восстановления смотри ниже.
AuthError	Ошибка аутентификации. Аутентификационная проверка платежной схемы не прошла. Восстановление возможно. Чтобы определить, что допустимо, смотри приложение по платежным схемам.
InsuffFunds	Нехватает средств. Средств для осуществления платежа недостаточно. Опции восстановления смотри ниже.
InstBrandInvalid	Платежный инструмент не приемлем для данного вида платежа. Использован платежный инструмент, который не соответствует выбранному виду платжа. Например, использована кредитная карта Visa, хотя в качестве вида платежа была выбрана MasterCard. Опции восстановления смотри ниже.
InstNotValid	Платежный инструмент не приемлем для сделки. Платежный инструмент по каким-то причинам не может быть использован для предлагаемого вида сделки. Опции восстановления смотри ниже.
BadInstrument	Плохой инструмент. Имеется проблема с использованным платежным инструментом, что означает, что он не может быть применен для платежа. Опции восстановления смотри ниже.
Unspecified	Неспецифицированная ошибка. Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Атрибут StatusDesc должен предоставить объяснение причины. Опции восстановления смотри ниже.
TimedOutRcvr	Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение другой торговой роли получено снова.
TimedOutNoRcvr	Невосстановимый таймаут. Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно.

Если оплата не зависит от вида платежа, тогда восстановление для некоторых видов кода завершения возможно для покупателя, который может выбрать другой вид платежа или новый платежный инструмент для того же вида платежа. Заметим, что это может потребовать замены кассира. Здесь применимы следующие коды: BrandNotSupp, PaymtCancelled, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument и Unspecified.

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

7.16.3. Коды завершения доставки

Платежный обмен

Рисунок .3. Платежный обмен

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

Компонент списка типов платежей содержит перечень допустимых видов платежа (например, MasterCard, Visa, Mondex, GeldKarte), платежные протоколы (например, SET Version 1.0, SCCD (Secure Channel Credit Debit – имя, используемое для платежей через кредитные карточки, где неавторизованный доступ блокируется с помощью механизма формирования безопасного транспортного канала, такого как SSL/TLS), а также сумма и вид валюты. Продавец посылает список типов платежей покупателю. Покупатель сравнивает типы платежей, протоколы, тип валюты и сумму со своими возможностями и делает выбор.

Компонент выбора типа платежа содержит выбор покупателя. Тип платежа, протокол, вид валюты, сумма и возможно протокольно зависимая информация посылается продавцу. Эта информация используется для модификации данных предложения (Offer Exchange). Например, продавец может предложить скидку, с тем, чтобы стимулировать использование карточки накопления (store card).

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

Компоненты Организаций генерируются Продавцом. Они содержат детали ролей Продавца и Кассира:

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

Компонент платеж содержит данные о сумме платежа, валюте и направлении оплаты (кто кому).

Компонент подпись "Offer Response", если присутствует, цифровым образом подтверждает целостность и корректность всех остальных компонентов.
Заметим, что компоненты списка типов платежа (Brand List) и выбор типа платежа (Brand Selection) не подписываются до тех пор, пока платежные данные не сформированы (шаг 4 на диаграмме).

Компонент данные о торговых ролях (Trading Role Data) содержит информацию о других ролях (например, продавца), о которых нужно проинформировать кассира.

Компонент схема платежа (Payment Scheme) содержит сообщения платежного протокола, используемого при сделке. Например, это могут быть сообщения SET, сообщения Mondex, сообщения GeldKarte или какого-то другого метода платежа, поддерживаемого IOTP. Содержимое компонента схема платежа (Payment Scheme) определено в приложениях, которые описывают то, как работает IOTP с различными платежными протоколами.

Компонент платежной расписки (Payment Receipt) содержит запись о платеже. Содержимое зависит от используемого платежного протокола.

Компонент подпись платежной расписки (Payment Receipt) предоставляет подтверждение корректности платежа путем цифровой подписи компонентов платежной расписки и подписи отклика-предложения. Подпись предложения гарантирует целостность и корректность компонентов заказа, организаций, и доставки, содержащихся в предложении. Эта подпись соединяет платеж и предложение.

Пример платежного обмена представленного выше, является наиболее общим случаем. Возможны и более простые варианты. Например, если сумма платежа не зависит от выбранного типа платежа и платежного протокола, тогда информация, генерируемая на этапе 3, может быть послана покупателю одновременно с формированием компонента список типов платежей (Brand List) на этапе 1. Эти и другие вариации описаны в разделе базовые торговые операции IOTP (смотри раздел 9.1.8).

2.2.3. Обмен доставки

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


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

1.	Покупатель решает осуществить сделку и посылает информацию продавцу о том, что нужно доставить и как это лучше сделать.
C a M	Информация о том, что следует доставить (вне зоны ответственности IOTP)
2.	Продавец проверяет информацию, полученную от покупателя, добавляет информацию о том, как будет осуществляться доставка, информацию об организациях, вовлеченных в доставку и, опционно, электронную подпись, после чего отправляет все это покупателю.
C ? M	Компоненты: lоставка; jрганизации (fгент доставки, доставит туда-то); заказ, опционная подпись отклика-предложения
3.	Покупатель проверяет, корректна ли доставочная информация, получает разрешение на доставку, например путем оплаты, и посылает эти данные агенту доставки.
C a D	Запрос доставки. Компоненты: cтатус; доставка, организации: (продавец, агент доставки, DelivTo); Заказ, данные о торговой роли (опционны); опционная подпись отклика-предложения, опционная подпись платежной расписки (из платежного обмена)
4.	Агент доставки проверяет информацию и авторизацию. Запускает или диспетчеризует доставку, а также готовит и отправляет накладную покупателю, которая опционно может быть подписана.
C ? D	Отклик доставки. Компоненты: статус; накладная (Delivery Note), данные о торговой роли (опционны); опционная подпись отклика доставки
5.	Покупатель проверяет накладную и принимает товар или ждет доставки, как это указано в накладной (Delivery Note).

Подписи при обмене ценностями

Рисунок .30. Подписи при обмене ценностями

9.1.12. Допустимые комбинации документальных обменов Диаграмма на Рисунок .31. иллюстрирует информационные условия в различных IOTP-сообщениях, которые могут быть использованы покупателем, чтобы определить допустима или нет конкретная комбинация документальных обменов.

Получение логотипов

10. Получение логотипов

Ниже описано, как извлекать логотипы для отображения их программой IOTP, используя атрибут Logo Net Locations, содержащийся в элементе вида платежа (смотри раздел 7.7.1) и компоненте Organisation (смотри раздел 7.6). Полный адрес логотипа определяется следующим образом: Logo_address ::= Logo_net_location "/" Logo_size Logo_color_depth ".gif"
Где:

Logo_net_location получено из атрибута LogoNetLocn элемента вида платежа (смотри раздел 7.7.1) или компонента Organisation. Заметим, что:

- содержимое этого атрибута зависит от используемого транспортного механизма (такого как HTTP).

- разработчики должны проверить, что если самый правый символ в Logo Net Location представляет собой "/", тогда другой такой же символ не должен включаться в запись адреса логотипа

Logo_size идентифицирует размер логотипа,

Logo_color_depth идентифицирует насыщенность цвета логотипа;

"gif" идентифицирует, что логотип имеет формат "gif" .

Logo_size и Logo_color_depth специфицирует разработчик программы IOTP, которая извлекает логотип, в зависимости от размера и цвета, который желательно иметь.
10.1. Размер Logo
Имеется пять стандартных рамеров логотипа. Размеры в пикселях соответствуют в таблице значениям размера логотипа.

Размер в пикселях	Размер логотипа значение
32 x 32 или 32 x 20	exsmall (сверх малый)
53 x 33	small (малый)
103 x 65	medium (средний)
180 x 114	large (большой)
263 x 166	exlarge (сверх большой)

10.2. Насыщенность цвета логотипа
Существует три стандартных значения насыщенности цвета. Насыщенность цвета (включая число бит на пиксель) и соответствующее значение для Logo_Color_Depth представленны ниже в таблице.

Насыщенность цвета	Цвет логотипа
(бит на пиксель)	Значение насыщенности
4 (16 цветов)	4
8 (256 цветов)	ничего
24 (16 миллионов цветов)	24

Заметим, что если насыщенность цвета логотипа пропущена, тогда извлекается логотип с 256 цветами.
10.3. Примеры логотипа для сетевой позиции
Если логотип сетевой позиции равен "ftp://logos.xzpay.com", тогда:

"ftp://logos.xzpay.com/medium.gif" извлечет логотип среднего размера с 256 цветами

"http://logos.xzpay.com/small4.gif" извлечет логотип малого размера с 16 цветами

Организации, которые делают логотип доступными для работы с IOTP должны всегда допускать размеры "small" и "medium" и использовать формат "gif".

Предложение

Рисунок .2. Предложение

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

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

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

	Покупатель предоставляет информацию о том, кто он и, если товар или услуги доставлены, место, куда они доставлены.
	Продавец дополняет эту информацию данными о себе, о Кассире, Агенте обслуживания Покупателя и, если товар или услуга должна быть доставлена, то и об агенте доставки.

o	Компонент Заказа (Order Component) содержит описания товаров или услуг, предмет сделки, если покупателя устроит соглашение. Эта информация посылается Продавцом покупателю.
o	Компонент оплаты (Payment Component), генерируемый продавцом, содержит детали того сколько надо платить, в какой валюте и кто должен платить кому, например покупатель может попросить вернуть деньги. Заметим, что число платежей в сделке может быть больше одного.
o	Компонент Доставки (Delivery Component), также генерируемый продавцом, используется, если товары или услуги требуют доставки. Он содержит информацию о том, как будет осуществляться доставка, например с помощью обычной или электронной почты.
o	Компонент данных о торговых ролях содержит информацию, которую продавец хочет довести до сведения другой торговой роли, такой как Кассир или Агент доставки.
o	Компонент подпись "отклика на предложение", если присутствует, подписывает все выше перечисленные компоненты с целью гарантии их целостности.

Точное содержание информации, выданной Продавцом Покупателю, варьируется в зависимости от типа операции IOTP. Например:

низкая стоимость сделки может не требовать подписи

сумма оплаты может варьироваться в зависимости от фирмы и используемого протокола оплаты

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

обмен ценностями включает два платежа

продавец может не предлагать покупателю каких-либо услуг.

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

Используя [HTML] страницы, как часть "практики" покупателей.

Используя стандарт OPS (Open Profiling Standard), который был недавно предложен,

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

Как компоненты Заказа в последней версии IOTP.

2.2.2. Платежный обмен

Целью платежного обмена (Payment Exchange) является оплата, производимая покупателем еассиру или наоборот, используя вид и протокол платежа, выбранные покупателем. Второй целью является опционное обеспечение покупателя платежной распиской (Payment Receipt), которая может использоваться для связи платежа с его причиной, как это описано в обмене предложения (Offer Exchange).

Обмены платежа могут реализовываться различными способами. Наиболее общий случай, где сделка зависит от типа и платежного протокола, показан на диаграмме Рисунок .3. Возможны и более простые платежные обмены.

1.	Покупатель решает что-то купить и посылает информацию об этой операции (запрос предложения) Продавцу, напр., используя HTML.
C a M	Информация о том, что покупается (вне рамок стандарта IOTP)
2.	Продавец решает, какой тип и протокол платежа следует предложить, записывает эти данные в компонент Brand List и посылает покупателю.
C ? M	Компоненты: список типов платежей (Brand List)
3.	Покупатель выбирает тип платежа, протокол и вид валюты, формирует компонент выбор типа и посылает его продавцу.
C a M	Компонент: Выбор из списка типов платежа (Brand List Selection)
4.	Продавец проверяет выбор типа, определяет сумму платежа, опционно подписывает документ и посылает его Покупателю.
C ? M	Компонент: Платеж; Организации (продавец и кассир); опционная подпись отклика-предложения, которая подтверждает другие компоненты.
5.	Покупатель проверяет объявленную сумму платежа и, если согласен, посылает запрос кассиру.
C a P	ЗАПРОС ПЛАТЕЖА. Компоненты: Статус, Платеж; Организации (продавец и Кассир); Информация о торговых ролях (опционно); опционная подпись отклика-предложения, которая подтверждает все прочие компоненты. Данные о схеме платежа.
6.	Кассир проверяет информацию, включая опционную подпись и, если все в порядке, начинает обмен компонентами данных по схеме платежа с целью выбора типа и протокола платежа.
C « P	ПЛАТЕЖНЫЙ ОБМЕН. Компонент: Данные о схеме платежа
7.	Как только обмен протокольными платежными сообщениями завершится, Кассир посылает Покупателю платежную расписку, которая опционно подписывается, с целью подтверждения платежа.
C « P	ОТКЛИК на ПЛАТЕЖ. Компоненты: Статус, платежная расписка; платежное заявление; данные о торговых ролях (опционно); опционная подпись отклика-предложения; опционная подпись платежной расписки, которая связывает платеж и предложение
8.	Покупатель проверяет платежную расписку

фрагментации пакета

Рисунок 4.1.1.3.6. Пример фрагментации пакета

Куда будет направлен Ethernet-кадр, указывает значение для типа в заголовке кадра (Рисунок 4.1.1.3.5). Если IP-пакет попадает в модуль IP, то содержащиеся в нем данные могут быть переданы либо модулю TCP (Transmission Control Protocol), либо UDP, что определяется полем "протокол" в заголовке IP-пакета. Одним из основополагающих понятий в теории маршрутизации является автономная система (AS). Автономную систему составляет IP-сеть (или система из нескольких IP-сетей), проводящая единую политику внешней маршрутизации и имеющая одного или более операторов. Все AS имеют уникальные номера. Идеология AS позволяет решить проблему безудержного роста размера таблиц маршрутизации. Построение узла Интернет неотделимо от формирования локальной сети, поэтому прежде чем перейти к углубленному описанию протоколов TCP/IP, введем определения некоторых сетевых устройств, без которых построение локальной сети невозможно.

использование подписи при покупке

Рисунок .11. Пример использование подписи при покупке

6.1.2. Элементы OriginatorInfo и RecipientInfo Атрибут OriginatorRef элемента OriginatorInfo в компоненте подписи содержит ссылку на элемент (смотри раздел 3.5), которая указывает на комполнент организации, сгенерировавшей подпись. В данном примере это продавец.
Заметим, что значение элемента атрибута с атрибутом типа, устанавленным равным типу подписи IOTP, должно соответствовать торговой роли организации, которая его подписала. Если это не так, возникает ошибка. Корректные значения представлены ниже в таблице.

Тип подписи IOTP	Корректная торговая роль
OfferResponse	Продавец
PaymentResponse	Кассир
DeliveryResponse	Агент доставки
AuthenticationRequest	Любая роль
AuthenticationResponse	Любая роль
PingRequest	Любая роль
PingResponse	Любая роль

Атрибут RecipientRefs элемента RecipientInfo в компоненте подписи содержит ссылки элементов на компоненты организации, которая должна использовать подпись, чтобы проверить:

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

Заметим, что, если используется симметричная криптография, отдельные элементы RecipientInfo и Value для каждого набора общих секретных ключей размещаются в компоненте Signature. В противном случае, если используется асимметричная криптография, атрибут RecpientRefs одного элемента RecipientInfo может относиться к нескольким компонентам Organisation, если они все используют один и тот же сертификат.
6.1.3. Использование подписей для подтверждения корректного завершения операций
Проверка успешного завершения операции осуществляется с помощью подписи данных сообщений-откликов. В частности:

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

	- Кассиру, чтобы проверить, что продавец авторизует платеж;
	- Агенту доставки, чтобы проверить, что продавец авторизует доставку.

Для платежного отклика, когда Кассир генерирует платежную расписку, которая может быть послана:

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

Отклик доставки, когда Агент доставки генерирует накладную (Delivery Note). Это может быть использовано, чтобы проверить по завершении, что все сделано так как надо.

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

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

Ping. Отклик Ping может быть подписан, чтобы иметь возможность проверки распознаваемости подписи.

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

проверка того, что блок подписи присутствует и содержит один или более компонентов подписи;

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

использование ID-атрибута компонента организации, чтобы найти элемент RecipientInfo, который содержит атрибут RecipientRefs, имеющий отношение к компоненту Organisation. Заметим, что может не быть подписи и по этой причине нечего проверять.

проверка компонента Signature, который содержит идентифицированный элемент RecipientInfo в виде:

	- используются атрибуты SignatureValueRef и SignatureAlgorithmRef, чтобы идентифицировать, соответственно: элемент Value, который содержит подпись, подлежащую проверке и элемент алгоритма подписи, который характеризует алгоритм вычисления подписи, предназначенный для ее верификации, затем
	- если элемент алгоритма подписи указывает, что использована асимметричная криптография, тогда для идентификации сертификата применяется SignatureCertRef;
	- если элемент алгоритма подписи указывает, что использована симметричная криптография, тогда для идентификации корректного значения общего ключа используется содержимое элемента RecipientInfo;
	- используется специфицированный алгоритм подписи для проверки того, что элемент Value правильно подписывает элемент Manifest;
	- проверется, что элементы Digest в элементе Manifest вычислены правильно. При этом предполагается, что компоненты или блоки, на которые ссылается дайджест, были получены организацией, выполняющей проверку подписи.

<


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

проверка того, что платежный запрос или запрос доставки посланы правильной организацией;

проверка того, что в запросе представлены правильные компоненты IOTP;

проверка того, что платеж или доставка авторизованы.

В данном разделе используются следующие термины:

"Блок запроса" используется в связи с блоком запроса платежа (смотри раздел 8.7) или блоком запроса доставки (смотри раздел 8.10), если не специфицировано обратного;

"Блок отклика" используется в связи с блоком платежного отклика (смотри раздел 8.9) или блоком отклика доставки (смотри раздел 8.11);

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

"Операционная организация" используется в отношении Кассира или Агента доставки, которые реализуют операцию;

"Подписант операции" используется в отношении организации, которая подписаладанные об операции с целью ее авторизации;

"Верификатор операции" используется в отношении организаций, которые верифицируют данные, чтобы определить, авторизованы ли они для выполнения операции;

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

6.3.1. Проверка того, что блок запроса послан правильной организацией
Проверка того, послан ли блок запроса правильной организации, варьируется в зависимости от того платеж это или доставка.
6.3.1.1. Платеж
Кассир проверяет, может ли он принять или выполнить платеж путем идентификации компоненты платежа в полученном им блоке платежного запроса. Затем, используя ID плетежного компонента для идентификации организации, выбранной Покупателем, проверяет, что это та самая организация.Метод доступа к данным для решения поставленных задач проиллюстрирован на Рисунок .12.

использования ID-атрибутов

Рисунок .8. Пример использования ID-атрибутов

3.5. Элемент References Торговый компонент или один из его дочерних XML элементов может содержать XML-атрибут, который указывает на другой блок (т.e. Блок ссылок транзакции или торговый блок) или торговый компонент (включая идентификатор транзакции и компонент подписи). Эти ссылки элементов используются для многих целей, ниже предлагается несколько примеров:

Идентификация элементов XML, чей дайджест включен в компонент подписи.

Указание на компонент организации кассира, который используется при платеже.

Элементы Reference всегда содержат значение ID-атрибута блокаили компонента. Идентификация сообщения IOTP, торговогоблока или торгового компонента, на который указывает ссылка элемента, включает в себя наождение XML-элемента, который:

Принадлежит той же самой IOTP-транзакции (т.e. Id-компонет транзакции и IOTP-сообщения совпадают).

Имеет значение ID-атрибута элемента соответствующее значению ссылки элемента.

Термин "соответствует" в данной спецификации имеет то же определение, что и в [XML]. Пример "соответствия" ссылки элемента показан ниже.

Пример маршрутной таблицы

Рисунок 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 октет

Субполе описание маршрута Number определяет IP-адрес места назначения, для экономии места здесь используется только 3 его байта.


Если поле задержки содержит только единицы, место назначения недостижимо.
Пропускная способность измеряется в величинах, обратных бит/сек, умноженных на 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

Комбинированная метрика в действительности вычисляется по следующей формуле (для версии Cisco 8.0(3)):
Метрика = [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

Протокол IGRP разработан фирмой CISCO для своих многопротокольных маршрутизаторов в середине 80-х годов. Хотя этот протокол и не является стандартным, я счел возможным включить его описание, так как маршрутизаторы этой фирмы относятся к наиболее массовым. IGRP представляет собой протокол, который позволяет большому числу маршрутизаторов координировать свою работу. Основные достоинства протокола (описание протокола взято из депозитария FTP.CISCO.COM/pub/igrp.doc).

стабильность маршрутов даже в очень больших и сложных сетях;

быстрый отклик на изменения топологии сети;

минимальная избыточность. Поэтому 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

Протокол IMAP 4.1 (INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1, V.Crispin, RFC-2060, December 1996) базируется на транспортном протоколе TCP и использует порт 143. Протокол IMAP представляет собой альтернативу POP-3. Также как и последний он работает только с сообщениями и не требует каких-либо пакетов со специальными заголовками.
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).

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 не совпадает с полученным в блоке платежного запроса, это вызывает ошибку.

6.3.1.2. Доставка

Способ доступа к данным Агента доставки при проверке того, может ли он выполнить доставку показан на Рисунок .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	Команда неизвестна или неверен аргумент.

Команда EXAMINE идентична команде SELECT и дает тот же результат, однако, выбранный почтовый ящик идентифицируется как “только для чтения”. Никакие изменения постоянного состояния почтового ящика в этом случае не разрешены. Текст маркированного отклика OK на команду EXAMINE должен начинаться с кода отклика "[READ-ONLY]".

Пример: 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	команда неизвестна или неверен аргумент.

Команда CREATE создает почтовый ящик с заданным именем. Отклик OK присылается в случае, когда новый почтовый ящик с указанным именем создан. Попытка создания INBOX или почтового ящика с именем, существующего почтового ящика, является ошибкой . Любая ошибка при попытке создания почтового ящика вызовет маркированный отклик NO.

Если имя почтового ящика имеет суффикс с символом сепаратора иерархии сервера (в соответствии с тем, что получено при выполнении команды 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	команда неизвестна или неверен аргумент.

Команда RENAME изменяет имя почтового ящика. Маркированный отклик OK присылается лишь в случае, когда почтовый ящик переименован. Считается ошибкой попытка переименовать не существующий почтовый ящик или присвоить ящику уже имеющееся имя. Любая ошибка при переименовании вызовет маркированный отклик NO.

Если ящик содержит в себе иерархическую структуру, имена этой структуры не должны меняться. Например, переименование "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 возвращает субнабор имен из полного набора, доступного клиенту. Присылается нуль или более немаркированных откликов LIST, содержащих атрибуты имен, иерархические разделители и имена.

Команда 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/*

Первые три примера демонстрируют интерпретацию в контексте аргумента шаблона. Заметьте, что "~smith/Mail" не должно преобразоваться во что-то подобное "/u2/users/smith/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 возвращает субнабор имен из списка пользователя, который декларирован как "активный" или "подписной". При этом отправляется нуль или более немаркированных откликов LSUB. Аргументы LSUB имеют тот же формат, что и для команды LIST.

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


Если имени не существует, оно должно быть помечено в отклике 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

Пример: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)


S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
S: A042 OK STATUS completed

5.3.11. Команда APPEND

Аргументы: имя почтового ящика,
опционно – флаг списка со скобками,
опционно – строка даты и времени,
литерал сообщения

Отклики: команда не требует какого-либо специального отклика

Результат:	OK	команда успешно исполнена
NO	команда не прошла: добавление в почтовый ящик не удалось, ошибка во флагах или дате/времени, или в тексте сообщения
BAD	команда неизвестна или неверен аргумент

Команда APPEND добавляет литеральный аргумент в качестве нового сообщения в почтовый ящик. Этот аргумент должен следовать формату сообщений [RFC-822]. Допускается использование в сообщениях 8-битовых символов. Реализация сервера, которая не может работать с 8-битовыми данными, должна быть способна преобразовывать 8-битовую информацию APPEND в 7-битовую, используя транспортное кодирование [MIME-IMB]. Если специфицирован флаг списка со скобками, в результирующих сообщениях должны быть установлены флаги, в противном случае список флагов будет установлен по умолчанию пустым.

Если специфицировано 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	Уникальный идентификатор сообщения.

Пример: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])


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, но без возвращения нового значения.

Пример: C: A003 STORE 2:4 +FLAGS (\Deleted)
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	команда неизвестна или неверен аргумент.

Команда COPY копирует специфицированное сообщение в конец указанного почтового ящика.


Флаги и внутренняя дата сообщения должны быть сохранены в копии.

Если указанный почтовый ящик отсутствует, сервер должен прислать сообщение об ошибке. Он не должен автоматически создавать почтовый ящик. Если заведомо не известно, что ящик не может быть создан, сервер должен послать код отклика "[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	Почтовый ящик не содержит каких-либо дополнительных сообщений, со времени, когда почтовый ящик последний раз был выбран.

Если сервер не может определить, является ли почтовый ящик “интересным”, или, если имя имеет атрибут \Noselect, сервер не должен посылать отклики \Marked или \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	Число, выражающее уникальный идентификатор сообщения.

Пример: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)

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" или подобной организации.

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

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

Ниже приводится список некоторых причин, почему электронная подпись может не использоваться:

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

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

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 = "ISO4217-A", тогда код валюты является буквенным, определенным в [ISO4217].

Если CurrCodeType = "IOTP", тогда новые значения должны быть опубликованы через торговый подписной лист IETF и, если в течение трех недель не поступает возражений, они присваиваются в порядке поступления.

Код типа валюты IOTP, сконструирован так, чтобы позволять поддержку "новых" псевдовалют, таких как loyalty или frequent flyer points. На момент написания этого документа ни один из таких кодов не был лпределен.

Тип элемента/Имя атрибута	Значения атрибута
Валютная сумма/CurrCodeType	"ISO4217A" "IOTP"

Новые значения атрибута CurrCodeType выделяются после публикования через подписной лист IETF и рассмотрения экспертами.

DeliveryData/DelivMethod

"Post" "Web" "Email"

Новые значения атрибута Delivery Method выделяются после публикования через подписной лист IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как используется данный метод доставки.

PackagedContent/Content

"PCDATA" "MIME" "MIME:mimetype" (где mimetype должен быть тем же, что и в content-type, как это определено в [MIME]) "XML"

Если атрибут Content имеет форму "MIME:mimetype", тогда управление новыми значениями для "mimetype" определено в [MIME].

В противном случае, новые значения атрибута Content выделяются после публикования через подписной лист IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как используется новый атрибут в элементе Packaged Content.

RelatedTo/RelationshipType

"IotpTransaction" "Reference"

Новые значения атрибута RelationshipType выделяются после публикования через подписной лист табочей группы IETF и рассмотрения экспертами.


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

Тип элемента/Имя атрибута	Значения атрибута
Status/StatusType	Предложение Платеж Доставка Аутентификация Не идентифицировано Новые значения атрибута Status Type выделяются после: oпубликации в Торговой Рабочей Группе IETF, документа RFC, описывающего торговый обмен, торговые роли и соответствующие компоненты, которые относятся к Status и oрассмотрения документа в торговом почтовом листе IETF и экспертами.

Документ, описывающий новые значения атрибута Status Type, может быть объединен с документами, описывающими новые торговые роли и типы подписей (смотри ниже).

TradingRole/TradingRole

"Consumer" "Merchant" "PaymentHandler" "DeliveryHandler" "DelivTo" oрассмотрения документа в торговом почтовом листе IETF и экспертами.

Документ, описывающий новые значения атрибута Trading Role может быть объединен с документами, описывающими новые значения Status Types (смотри выше) и типы подписей (смотри ниже).

Тип элемента/Имя атрибута	Значения атрибута
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.

Рекомендуется использование имен доменов (смотри [DNS]), для того чтобы сделать коды, определенные пользователем, уникальными, хотя этот метод и не является совершенно надежным.

Список видов атак, зарегистрированных 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.

Ссылки элемента (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.
	- содержимое дополнительного элемента следует игнорировать, за исключением случая, когда оно должно учитываться при генерации дайджеста в ходе формировании электронной подписи.

Если дополнительный XML-элемент не имеет атрибута "IOTP:Critical", тогда он должен обрабатываться так, как если бы имел атрибут "IOTP:Critical" со значением "True"

Если XML-элемент содержит атрибут "IOTP:Critical", тогда значение атрибута следует использовать во всех дочерних элементах этого элемента.

Для того чтобы гарантировать то, что документы, содержащие "IOTP:Critical" корректны, этот атрибут объявляется частью DTD для дополнительных элементов в форме:

IOTP:Critical

(True | False ) 'True'

3.6.2. Opaque Embedded Data

Если IOTP должен быть расширен с помощью Opaque Embedded Data, тогда к инкапсулированным данным должен быть применен элемент Packaged Content (смотри раздел 3.7).

3.7. Элемент PackagedContent

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

o для инкапсуляции сообщений платежной системы, таких как сообщения SET,
o для инкапсуляции описания заказа, чека (payment note) или накладной (delivery note).

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





Атрибуты:

Name	Опционно. Позволяет разделить случаи множественного применения элементов PackagedContent в одной и той же точке IOTP. Например:

snroasdfnas934k

dvdsjnl5poidsdsflkjnw45



Атрибут имени может быть опущен, например, если имеется только один элемент 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	Идентифицирует преобразование, которое было произведено нс даннвми, прежде чем они были помещены элемент. Допустимыми значениями являются:

NONE. Содержимое элемента PackagedContent типа PCDATA является корректным представлением данных. Заметим, что разворачивание объекта должно быть произведено (т.e. замена & и ) до анализа данных. Секции CDATA могут встречаться в элементе PackagedContent, где атрибут Transform равен NONE.

BASE64. Содержимое элемента PackagedContent типа PCDATA представляет собой BASE64 кодировкуреального содержимого.

Cодержимое:

PCDATA

Это действительные данные, которые вложены в элемент. Формат данных и правила их кодирования записаны в атрибутах Content и Transform.

3.7.1. Packaging HTML

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.

Ссылки

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: .
[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.

Структура адресов 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 Семенов Ю.А. (ГНЦ ИТЭФ) 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 доступна пользователям сетей EARN/Bitnet через интерактивный обмен (SEND-команда в VMS/JNET, или PHONE в VAX/VMS). Все ЭВМ-серверы RELAY - это IBM VM/CMS системы, но вам не нужно быть пользователем VM, для того чтобы использовать RELAY. Если вы не в сети EARN/Bitnet, доступ к системе RELAY для вас закрыт. CHART доступен на любом NETSERV.
При регистрации клиенту посылаются файлы 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)" Продавца или какую-то другую гарантию на товары или услуги.

8.2. Блок выбора TPO

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




Атрибуты:

ID	Идентификатор, который однозначно определяет блок выбора TPO транзакции IOTP.

Cодержимое:

BrandSelection

Идентифицирует выбор вида платежаи платежного протокола, которы следует использовать при оплате в транзакции IOTP. Имеется один компонент выбора вида платежа (смотри раздел 7.8) для каждого предстоящего платежа транзакции IOTP.

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

8.3. Блок отклика Offer

Блок отклика Offer содержит подробности о товарах, услугах, сумме, инструкций доставки или финансовых операциях, которые должны быть осуществлоены. Его определение дано ниже.




Атрибуты:

ID	Идентификатор, который однозначно определяет блок отклика Offer транзакции.

Cодержимое:

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).

Блок отклика Offer должен содержать:

компонент Order транзакции;

компоненты Payment для каждой проплаты транзакции;

компонент Delivery транзакции (если предусмотрено).

8.4. Блок запроса аутентификации

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

информацию о том, как аутентифицировать себя и/или

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

Его определение предагается ниже.




Атрибуты:

ID	Идентификатор, который однозначно определяет блок запроса аутентификации транзакции.

Cодержимое:

AuthReq

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

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

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

TradingRoleInfoReq

Компонент информационного запроса торговой роли (смотри раздел 7.4) содержит список торговых ролей, данные о которых запрашиваются.

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

8.5. Блок отклика аутентификации

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




Атрибуты:

ID	Идентификатор, который однозначно определяет блок отклика аутентификации транзакции.

Cодержимое:

AuthResp	Опционный компонент аутентификационного отклика, который содержит результаты обработки компонента запроса аутентификации – смотри раздел 7.3.
Org	Опционные компоненты Organisation, которые содержат информацию, соответствующую торговым ролям, как это запрошено атрибутом TradingRoleList компонента информационного запроса торговой роли.

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

8.6. Блок состояния аутентификации

Блок состояния аутентификации индицирует успех или неудачу верификации блока отклика аутентификации аутентификатором. Его определение представлено ниже.




Атрибуты:

ID	Идентификатор, который однозначно определяет блок состояния аутентификации транзакции.

Cодержимое:

Status

Содержит статусную информацию об успехе или неудаче аутентификации (смотри раздел 4.2).

8.7. Блок платежного запроса

Блок платежного запроса содержит информацию, которая запускает процедуру платежа. Его описание представлено ниже.

Payment, PaySchemeData?, Org*, TradingRoleData*)>


Атрибуты:

ID	Идентификатор, который однозначно определяет блок платежного запроса транзакции.

Cодержимое:

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.


Блок платежного обмена

Блок платежного обмена содержит специфические данные о платежной схеме, которыми обмениваются две торговые роли в рамках сделки. Его определение представлено ниже.




Атрибуты:

ID	Идентификатор, который однозначно определяет блок платежного обмена транзакции.

Cодержимое:

PaySchemeData

Этот торговый компонент содержит специфические данные о платежной схеме, смотри раздел 7.10.

8.9. Блок платежного отклика

Этот блок платежного отклика содержит информацию о состоянии платежа, опционной платежной расписке и опционные сообщения платежного протокола. Его определение представлено ниже.

PaymentNote?, TradingRoleData*)>


Атрибуты:

ID	Идентификатор, который однозначно определяет блок платежного отклика транзакции.

Cодержимое:

Status	Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) платежа. Заметим, что в блоке платежного отклика, значения ProcessState NotYetStarted или InProgress являются нелегальными.
PayReceipt	Содержит специфические данные о платежной схеме, которые могут быть использованы для верификации произведенного платежа. Смотри раздел 7.11. Он должен присутствовать, если атрибут ProcessState компонента Status равен CompletedOk. Атрибут PayReceipt является опционным.
PaySchemeData	Содержит специфические данные о платежной схеме, например, о сообщениях платежного протокола. Смотри также раздел 7.10.
PaymentNote	Содержит дополнительную, несвязанную с платежом информацию, которую кассир желает предоставить покупателю. Например, если выполнен отзыв сделки или осуществлен депозит, он может содержать данные о полученном балансе на счету, после того как данная операция завершена. Смотри раздел 7.12.
TradingRoleData	Компонент информации о торговой роли содержит данные, которые нужны для обмена между ролями, участвующими в транзакции (смотри раздел 7.17).

8.10.


Блок запроса доставки

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

ConsumerDeliveryData?, TradingRoleData*)>


Атрибуты:

ID	Идентификатор, который однозначно определяет блок запроса доставки транзакции.

Cодержимое:

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 является нелегальным.




Атрибуты:

ID	Идентификатор, который однозначно определяет блок отклика доставки транзакции.

Cодержимое:

Status	Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) доставки. Заметим, что в блоке отклика Delivery, ProcessState равный NotYetStarted или InProgress считается нелегальным.
DeliveryNote	Компонент Delivery Note содержит подробности о том, как будут доставляться товары или услуги (смотри раздел 7.15).

8.12. Торговый блок информационного запроса

Торговый блок информационного запроса содержит компоненттип запроса и опционно платежной схемы.




Атрибуты:

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

Cодержимое:

InquiryType	Компонент тип информационного запроса (смотри раздел 7.18), который содержит код типа запроса.
PaySchemeData	Компонент платежная схема (Payment Scheme) (смотри раздел 7.10), который содержит специфические данные конкретных информационных запросов о платежной схеме. Он присутствует, когда атрибут Type компонента типа запроса равен Payment.

8.13. Торговый блок информационного отклика

Торговый блок информационного отклика содержит компонент Status и опционно компонент Payment Scheme. Его целью является осуществление запроса о текущем состоянии транзакции или сервера.


LastReceivedIotpMsgRef NMTOKEN #IMPLIED
LastSentIotpMsgRef NMTOKEN #IMPLIED >


Атрибуты:

ID	Идентификатор, который однозначно определяет торговый блок информационного отклика транзакции.
LastReceivedIotpMsgRef	Содержит ссылку элемента (смотри раздел 3.5) на Id-компонент (смотри раздел 3.3.2) последнего сообщения, которое получил данный сервер от покупателя. Если до этого не получено от покупателя ни одного сообщения, этот атрибут должен содержать значение (Null). Данный атрибут предназначен для отладочных целей.
LastSentIotpMsgRef	Содержит ссылку элемента (смотри раздел 3.5) на Id-компонент (смотри раздел 3.3.2) последнего сообщения, которое послал данный сервер покупателю. Если до этого не послано ни одного сообщения покупателю, данный атрибут должен содержать значение (Null). Этот атрибут предназначен для отладочных целей.

Cодержимое:

Status	Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) определенного торгового обмена (т.e., предложения, платежа или доставки).
PaySchemeData	Компонент Payment Scheme (смотри раздел 7.10), который содержит специфические информационные запросы по поводу платежной схемы. Он присутствует, когда атрибут Type атрибута StatusType компонента Status равен Payment.

8.14. Блок запроса Ping

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

Определение блока запроса Ping предложено ниже.




Атрибуты:

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

Cодержимое:

OrgОпционные компоненты Organisation (смотри раздел 7.6).

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

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

В этом случае отправитель включает:

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

Компонент Organisation, который идентифицирует получателя сообщения.

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


8.15. Блок отклика Ping

Блок отклика Ping предоставляет результат выполнения запроса Ping. Он содержит компонент Organisation, который идентифицирует отправителя отклика Ping.

Если запрос Ping, для которого этот блок является откликом, содержал компоненты Organisation, тогда он также содержит эти компоненты Organisation.


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, он может использоваться, например, для отладрчных целей.

Cодержимое:

Org	Компоненты Organisation (смотри раздел 7.6).

Компоненты Organisation отправителя отклика Ping всегда содержат кроме того компоненты Organisation, посланные в запросе Ping.


Значения статусного кода Ping не включают в себя такие значения как Fail, так как, когда программа, получающая сообщение запроса Ping, не работает, не будет послано никакого отклика Ping.

8.16. Блок подписи

Блок Signature содержит один или более компонентов Signature и соответствующих сертификатов (если требуется), которые подтверждают данные в рамках данной транзакции. Определение компонента Signature и сертификатов содержится в статье "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Описание их применения в IOTP можно найти в разделах 7.19 и 7.20.

Определение блока Signature представлено ниже:




Атрибуты:

ID	Идентификатор, который однозначно определяет блок подписи транзакции.

Cодержимое:

Signature	Компонент Signature. Смотри раздел 7.19.
Certificate	Компонент Certificate. Смотри раздел 7.20.

Содержимое блока Signature зависит от торгового блока, который содержится в том же сообщении, что и блок Signature.

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 представлена ниже.




Атрибуты:

ID	Идентификатор, который однозначно определяет блок Error транзакции.

Cодержимое:

ErrorComp	Компонент Error (смотри раздел 7.21), который содержит информацию об индивидуальной технической ошибке.
PaySchemeData	Опционный компонент Payment Scheme (смотри раздел 7.10), который содержит описание платежной схемы.

8.18. Блок Cancel

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


Пример использования включает в себя:

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

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

Его определение имеет вид.




Атрибуты:

ID	Идентификатор, который однозначно определяет блок Cancel транзакции.

Cодержимое:

Status

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

Торговые компоненты

7. Торговые компоненты

Далее рассматриваются торговые компоненты, используемые в IOTP. Торговые компоненты являются дочерними XML-элементами, что показано на диаграмме Рисунок .14.

Содержимое атрибута зависит от транспортного механизма.

SecureSenderNetLocn

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

Содержимое этого атрибута зависит от транспортного механизма.

SuccessNetLocn

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

Содержимое этого аптрибута зависит от транспортного механизма. Должен присутствовать либо SenderNetLocn, либо SecureSenderNetLocn или оба эти атрибута.

7.2. Компонент запроса аутентификации

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


AuthenticationId CDATA #REQUIREDContentSoftwareId CDATA #IMPLIED>

Если требуется, алгоритм может использовать данные вызова, содержащиеся в элементах Packaged Content из компонента запроса аутентификации. Формат Packaged Content является зависимым от алгоритма.

Атрибуты:

ID	Идентификатор, который однозначно идентифицирует компонент запроса аутентификации для данной транзакции IOTP.
AuthenticationId	Идентификатор, специфицированный аутентификатором, который, если прислан организацией, которая получает запрос, позволит аутентификатору определить, какая аутентификационная процедура требуется.
ContentSoftwareId	Смотри раздел 14. Словарь

Cодержимое:

PackagedContent	Содержит данные вызова в виде одного или более элементах Packaged Content (смотри раздел 3.7), на которые следует рееагировать, используя алгоритм, опреденный элементом Algorithm.
Algorithm	Содержит информацию, которая описывает алгоритм (смотри 7.19. Компоненты подписи), который должен быть использован для генерации отклика аутентификации.

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

7.3. Компонент отклика аутентификации

Компонент отклика аутентификации содержит результаты аутентификационного запроса.


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

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


AuthenticationId CDATA #REQUIREDSelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED >

Атрибуты:

ID	Идентификатор, который для данной транзакции однозначно определяет компонент отклика аутентификации.
AuthenticationId	Идентификатор аутентификации, специфицированный аутентификатором, который был включен компонент запроса (смотри раздел 7.2). Это позволяет аутентификатору идентифицировать метод аутентификации.
SelectedAlgorithmRef	Ссылка элемента, которая определяет элемент алгоритма, сипользуемого для формирования отклика аутентификации.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

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

Например, для заданной схемы платежа он может содержать данные, зависящие от этой схемы.

7.4. Компонент запроса информации торговой роли

Этот торговый компонент содержит список торговых ролей (смотри раздел 2.1), информация для которых запрошена. Результатом запроса торговой роли является набор компонентов Organisation (смотри раздел 7.6), которые описывают каждую из запрошенных торговых ролей. Его определение приведено ниже.


TradingRoleList NMTOKENS #REQUIRED >

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент информационного запроса для торговой роли в рамках транзакции IOTP.
TradingRoleList	Содержит список из одной или более торговых ролей (смотри атрибут TradingRole элемента Trading Role – раздел 7.6.2), для которых была запрошена информация.

7.5.


Компонент заказа

Компонент Order содержит информацию о заказе. Его определение представлено ниже.

xml:lang NMTOKEN #REQUIRED	OrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIRED	OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED	ApplicableLaw CDATA #REQUIRED

ContentSoftwareId CDATA #IMPLIED >

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент Order в пределах текущей транзакции IOTP.
xml:lang	Определяет язык, использованный атрибутами или дочерними элементами в пределах компонента, если только его значение не было изменено с помощью атрибута xml:lang дочернего элемента. Смотри раздел 3.8.
OrderIdentifier	Это код, число или другой идентификатор, который автор заказа может использовать для идентификации заказа. В пределах транзакции он должен быть уникальным. Если он используется так, то нет нужды специфицировать содержимое элемента заказа, так как имеется ссылка на нужную информацию в базе данных.
ShortDesc	Краткое описание заказа на языке, определенном атрибутом xml:lang. Оно используется для упрощения выбора индивидуального заказа из списка, например, из базы данных заказов, записанных туда продавцом, покупателем и т.д..
OkFrom	Дата и время в формате [UTC], после которого предложение, сделанное Продавцом теряет силу.
OkTo	Дата и время в формате [UTC], до которого получатель может воспринимать предложение продавца не имеющим силу.
ApplicableLaw	Фраза на языке, определенном атрибутом xml:lang, которая описывает штат или страну, юристдикция которой будет использована при разрешении конфликтов и споров.
ContentSoftwareId	Смотри раздел 14. Словарь.

Cодержимое:

PackagedContent

Опционное описание заказа в виде одного или более элементов Packaged Content (смотри раздел 3.7).

7.5.1. Содержимое описания заказа

Элемент 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.

Ниже представлено определение компонента.

xml:lang NMTOKEN #REQUIRED	OrgId CDATA #REQUIRED
LegalName CDATA #IMPLIED	ShortDesc CDATA #IMPLIED

LogoNetLocn 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

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

Смотри раздел 10. Содержимое этого атрибута должно соответствовать [RFC1738].

Cодержимое:

TradingRole	Смотри 7.6.2. Элемент торговой роли.
ContactInfo	Смотри 7.6.3. Элемент контактной информации.
PersonName	Смотри 7.6.4. Персональное имя.
PostalAddress	Смотри 7.6.5. Почтовый адрес.

7.6.1. ID организаций

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 уникальным.

Заметим, что NonConsumerOrgId не может начинаться с ConsumerOrgIdPrefix. Допускается использование строчных и прописных символов. Ниже приведены примеры Id организации:

newjerseybooks.comid организации-продавца;

westernbank.co.ukid организации-кассира;

consumer:1000247ABH/newjerseybooks.comid организации-покупателя выданный продавцом.

7.6.2. Элемент торговая роль

Этот элемент идентифицирует торговую роль человека или организации в данной транзакции IOTP. Заметим, что организация может иметь более чем одну торговую роль и несколько ролей может присутствовать в одном элементе Organisation.


Определение элемента представлено ниже:

TradingRole NMTOKEN #REQUIRED	IotpMsgIdPrefix NMTOKEN #REQUIRED
CancelNetLocn CDATA #IMPLIED	ErrorNetLocn CDATA #IMPLIED

ErrorLogNetLocn 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 равным:

HardError,

Предупреждение, но Покупатель решает не продолжать транзакцию.

TransientError и транзакция прерывается по таймауту.

Этот атрибут:

не должен присутствовать, когда TradingRole равно Покупатель или DelivTo,

должен присутствовать, когда TradingRole равно Продавец, Кассир или Агент доставки.

Содержимое атрибута зависит от транспортного механизма.

ErrorLogNetLocn

Опционно. Содержит сетевую позицию, куда Покупателю следует посылать IOTP сообщения, которые содержат блоки Error с компонентами Error сатрибутом Severity равным:

HardError,

Предупреждение, но Покупатель решает не продолжать транзакцию,

TransientError и транзакция прерывается по таймауту.

Этот атрибут:

не должен присутствовать, когда TradingRole = Покупатель,

должен присутствовать, когда TradingRole равно Продавец, Кассир или Агент доставки.

Содержимое этого атрибута зависит от транспортного механизма.

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

7.6.3. Элемент контактной информации

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

	NMTOKEN #IMPLIED
Tel CDATA #IMPLIED	Fax CDATA #IMPLIED
Email CDATA #IMPLIED	NetLocn CDATA #IMPLIED >

Атрибуты:

xml:lang	Определяет язык данного элемента. Смотри раздел 3.8.
Tel	Телефонный номер, по которому можно контактировать с организацией. Заметим, что это текстовое поле и проверок корректности содержимого не производится.
Fax	Номер факса, по которому можно контактировать с организацией. Заметим, что это текстовое поле и проверок корректности содержимого не производится.
Email	Адрес электронной почты, по которому можно контактировать с организацией. Заметим, что поле должно следовать регламентациям для адресных спецификаций, содержащимся в [RFC822].
NetLocn	Адрес Интернет, по которому можно найти информацию об организации, используя WEB-броузер.

Содержимое этого атрибута должно согласовываться с документом [RFC1738].


7.6.4. Элемент личного имени

Этот элемент содержит имя частного лица. Все поля являются опционными, однако GivenName (имя) или FamilyName (фамилия) должны присутствоать. Его опредление представлено ниже.

	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	Фамилия. Это обычно часть персонального имени, которая передается по наследству от родителей к детям.

7.6.5. Элемен почтового адреса

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

	NMTOKEN #IMPLIED
AddressLine1 CDATA #IMPLIED	AddressLine2 CDATA #IMPLIED
CityOrTown CDATA #IMPLIED	StateOrRegion CDATA #IMPLIED
PostalCode CDATA #IMPLIED	Country CDATA #IMPLIED

LegalLocation (True | False) 'False' >

Атрибуты:

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),

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

платежные протоколы, которые могут использоваться для реализации заданного вида платежа,

сетевые позиции Кассиров, которые воспринимают платеж в рамках платежного протокола.

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




xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED

PayDirection (Debit | Credit) #REQUIRED>

Атрибуты:

ID	Идентификатор, который однозначно определяет компонент списка видов платежа транзакции IOTP.
xml:lang	Определяет язык, использованный атрибутами или дочерними элементами в пределах данного компонента, если только его значение не переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.
ShortDesc	Текстовое описание на языке, заданном атрибутом xml:Lang, характеризующее цели списка видов платежа. Эта информация должна быть отображена у получателя списка видов платежа для того чтобы помочь сделать правильный выбор. Это привлекательно, так как позволяет Покупателю выяснить цели предлагаемого списка видов платежа, если транзакция предполагает несколько платежей.
PayDirection	Индицирует направление платежа для выбранного вида. Возможные значения:

Дебит. Отправитель блока платежного запроса (напр., покупатель), к которому имеет отношение список видов платежа, произведет платеж кассиру.

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

Cодержимое:

Brand	Описывает вид платежа (Brand). Последовательность элементов Brand (смотри раздел 7.7.1) в списке видов плптежа не определяет каких-либо преоритетов. Рекомендуется, чтобы программа, которая обрабатывает этот список видов платежа представляла их в порядке предпочтения получателя.
ProtocolAmount	Это связывает конкретный вид платежа с:

видами валюты и суммами в элементах CurrencyAmount, которые могут использоватьсясовместно с видами платежа, и

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

CurrencyAmount	Содержит код валюты и сумму платежа;
PayProtocol	Содержит информацию о платежном протоколе и Кассире, которые могут использовать данный вид платежа.

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

Торговые роли в 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, которые включают в себя один или более платежей. В частности:

- Депозит
- Покупка
- Возврат денег
- Отзыв сделки
- Обмен ценностями

Транзакции 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, чтобы правильно отразить сумму, которую следует оплатить.

второй (получение выгоды от эмитента платежного средства) – не требует, чтобы отклик Offer изменился;

каждый поощрительный вид оплаты в списке, предлагаемом продавцом, должен быть идентифицирован как отдельный вид платежа. Например: "Walmart", "Sears", "Marks and Spencer" и "American Advantage Visa", будут рассматриваться как отдельные виды оплаты.

11.1.5. Идентификация льготных видов платежа

Имеется две проблемы, которые нужно решить при идентификации поощрительных видов платежа:

как продавец или кассир идентифицирует поощрительный вид оплаты, используемый в момент покупки;

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

11.1.5.1. Идентификация поощрительных видов платежа Продавцом/Кассиром

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

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

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

Заметим, что:

первый вариант предполагает доступность SET.

второй – возможен, если продавец или кассир имеют доступ к базе данных эмитента карты.

IOTP не предоставляет продавцу информации о платежном инструменте (напр., карте или номере счета).


Эти данные посылаются кассиру в качестве части инкапсулированного платежного протокола. Это означает, что:

Продавец будет вынужден предположить, что выбранный платежный инструмент был льготным видом платежа, или

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

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

11.1.5.2. Выбор Покупателем льготных видов платежа

Существует два способа, как покупатель может выбрать правильно льготный вид платежа:

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

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

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

Покупатель непосредственно вводит этот код. Это располагает к ошибкам и неудобно для клиента, кроме того покупателю надо как-то передать этот код. Этот подход не рекомендуется,

Используется один из идентификаторов вида платежа, определенных в IOTP и предварительно загруженных в приложение покупателя,

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

	- сертификат SET для видов платежа, которые используют этот протокол оплаты;
	- код предоставляется платежной программой, которая работает с конкретным методом оплаты, это может быть приложимо к, например, GeldKarte, Mondex, CyberCash и DigiCash,

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

11.1.5.3.


Рекомендации для Id видов платежа в программе покупателя

Новые Id видов платежа выдаются в соответствии с процедурой, заданной IANA (смотри раздел 12).

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

11.2. Примеры видов платежа Данный пример содержит три образца XML для компонента списка видов платежа:

вариант с просой кредитной карточкой;

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

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

11.2.1. Простой пример, базирующийся на кредитной карте

Этот простой пример включает в себя:

только основные виды платежей с помощью кредитной карты;

одну цену и одну валюту;

одного Кассира и

один платежный протокол.

PayDirection='Debit' >
BrandLogoNetLocn='ftp://otplogos.mastercard.com/mastercardcredit'
ProtocolAmountRefs='M1.33'>

BrandLogoNetLocn='ftp://otplogos.visa.com/visacredit' ProtocolAmountRefs='M1.33'>

BrandLogoNetLocn='ftp://otplogos.amex.com' ProtocolAmountRefs ='M1.33' >




PayReqNetLocn='http://www.example.com/etill/sccd1' >



11.2.2. Список платежей с помощью кредитной карты, включая льготные платежи

Пример списка видов платежей с помощью кредитной карты представлен ниже.


Он включает в себя:

два обычных вида платежа через кредитную карту и два льготных вида платежа.

два платежных протокола:

	- SET (Secure Electronic Transactions) смотри [SET] и
	- SCCD (Secure Channel Credit Debit) смотри [SCCD].

BrandLogoNetLocn='ftp://otplogos.mastercard.com' ProtocolAmountRefs='M1.7 M1.8'>



BrandLogoNetLocn='ftp://otplogos.visa.com' ProtocolAmountRefs='M1.7 M1.8'>



BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk'
BrandNarrative='Double air miles with British Airways MasterCard'
ProtocolAmountRefs ='M1.7 M1.8' >



BrandLogoNetLocn='ftp://otplogos.walmart.com'
BrandNarrative='5% off with your Walmart Card on purchases over $150'
ProtocolAmountRefs='M1.8'>



238djqw1298erh18dhoire




238djqw1298erh18dhoire



ProtocolName='Secure Electronic Transaction Version 1.0'


PayReqNetLocn='http://www.example.com/etill/set1' >

8ueu26e482hd82he82


ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >

82hd82he8226e48ueu




11.2.3. Пример выбора вида платежа

Для оплаты через ' British Airways' MasterCard для выше приведенного варианта и платежного протокола SET список вида платежа будет иметь вид:

CurrencyAmountRef='M1.9' >


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

Ниже представлен достаточно сложный пример, который включает в себя:

платежи, использующие Mondex, GeldKarte, CyberCash или DigiCash;

в валютах, в список которых входят доллары США, британские фунты, итальянские лиры, немецкие марки и канадские доллары;

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

более одного Кассира для случаев использования Mondex или CyberCash;

поддержка более чем одной версии CyberCash для платежного протокола CyberCoin.

PayDirection='Debit'>
BrandLogoNetLocn='ftp://otplogos.mondex.com' ProtocolAmountRefs='M1.17 M1.18'>

BrandLogoNetLocn='ftp://otplogos.geldkarte.co.de' ProtocolAmountRefs='M1.19'>

BrandLogoNetLocn='http://otplogos.cybercash.com' ProtocolAmountRefs ='M1.20'>



BrandLogoNetLocn='http://otplogos.digicash.com'
BrandNarrative='5% off with your Walmart Card on purchases over $150'
ProtocolAmountRefs='M1.22'>

CurrencyAmountRefs='M1.25 M1.29'>

CurrencyAmountRefs='M1.26 M1.27 M1.28 M1.30'>



CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>

CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>









ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankus.com/etill/mx' >

ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankuk.com/vserver' >

PayReqNetLocn='http://www.cybercash.com/ccoin' >

PayReqNetLocn='http://www.cybercash.com/ccoin' >

PayReqNetLocn='http://www.example.com/pgway'>

ProtocolName='DigiCash Protocol Version 1.0'
PayReqNetLocn='http://www.example.com/digicash' >

Вложение пакетов Интернет в 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 - подтверждение.

Введение (общие принципы построения сетей)

1 Введение (общие принципы построения сетей)

Интернет является сетью виртуальных сетей. В 1991 году у нас (тогда еще в СССР) о нем знали несколько десятков человек, которые только что освоили электронную почту (через RELCOM) и попробовали, что такое FidoNet. Первое сообщение по электронной почте было послано президентом США Биллом Клинтоном 2 марта 1993 года. Первая новелла Стивена Кинга была опубликована по каналам Интернет 19 сентября 1993 года (до появления печатной копии), к тому же году относится начало синхронной передачи радио-программ по сетям Интернет. В конце 1993 года заработала первая очередь оптоволоконной опорной сети Москвы, полностью профинансированная Джорджем Соросом. В 1994 году НАТО организовало первую конференцию по Интернет в России (в Голицыно под Москвой). С помощью DFN (Deutsche Forschung Naetze), а затем Дж. Сороса и RELARN круг любителей Интернет расширился до сотен и тысяч, а после включения программ Минвуза и Министерства науки РФ счет пошел на десятки тысяч. Это произошло прежде всего потому, что созрели условия - в различных учреждениях (сначала научных, а затем коммерческих и государственных) и у частных лиц оказались сотни тысяч персональных ЭВМ. К этому же времени (1992-93 годы) в мире стала формироваться сеть депозитариев, доступных через анонимный доступ (FTP), а несколько позднее и WWW-серверов. На Рисунок 1.1 показан рост числа ЭВМ, подключенных к Интернет по годам с 1989 по 1998 годы. Видно, что рост числа узлов сети имеет экспоненциальный характер. Можно смело утверждать, что протоколы Интернет, созданные для осуществления связи в случае нанесения десятков ядерных ударов по США со стороны СССР, явились одним из немногих (возможно единственным) положительным результатом холодной войны.




    Безналичный оборот: Деньги - Расчеты - Карты

• Безналичный денежный оборот
  
• Регулирование безналичного денежного оборота
  
• Торговля золотом
  
• Пластиковые карты
  
• Безналичный денежный оборот в Интернете
  
  
• Международные деньги и расчеты
  
• Международные денежные союзы
  
• Международная экономика
  
• Деньги и расчеты в России
  

---

---