Протоколы Internet
Некоторые другие процедуры Интернет
4.5.16 Некоторые другие процедуры Интернет
NFS (network file system, sun microsystems, RFC-1094) обеспечивает прозрачный доступ к удаленным файлам так, что с точки зрения программиста эти файлы выглядят, как местные. При этом даже в написании имен файлов никак не проявляется их истинное местонахождение. NFS является частью операционной системы. Различие работы с местными и удаленными файлами проявляется лишь на системном уровне. Пользователь может почувствовать различие лишь по времени выполнения соответствующих операций обмена. nfs поддерживает операции по созданию, переименованию, копированию и стиранию файлов или каталогов и т.д.
Основой системы NFS является вызов удаленных процедур RPC, схема взаимодействия "клиент-сервер". NFS-сервер получает запросы от клиента в виде UDP-дейтограмм через порт 2049 (Рис. 4.5.16.1).
Рис. 4.5.16.1. Схема реализации nfs-системы клиент-сервер
RPC (Remote Procedure Call, RFC-1057) процедура, разработанная SUN microsystem, в настоящее время используется практически во всех системах, базирующихся на UNIX. RPC - это программа, которая реализует вызов удаленных подпрограмм, способствуя построению распределенных программ. Она позволяет программе, называемой клиентом, послать сообщение серверу. Далее программа-клиент ожидает сообщения-отклика. RPC работает совместно с универсальной системой представления внешней информации XDP (External Data Representation). Сообщение запрос содержит параметры, которые определяют, что должно быть сделано на удаленной ЭВМ. В свою очередь отклик несет в себе информацию о результатах выполнения запроса.
RPC может работать как на TCP, так и UDP транспортных уровнях. Использование RPC-техники упрощает программирование, так как не требует написания сетевых программ. Если используется протокол UDP, все что связано с обработкой тайм-аутов, повторных пересылок и пр. спрятано в внутри системных RPC-модулей. Формат RPC-запроса для UDP-версии показан на рис. 4.5.16.2.
Рис. 4.5.16.2. Формат RPC-запроса
Поле идентификатор процедуры устанавливается программой-клиента, пакет- отклик использует тот же идентификатор, что позволяет контролировать их соответствие. Каждый новый RPC-запрос имеет новый идентификатор. В настоящее время номер версии rpc равен 2. Следующие три поля содержат переменные: номер программы, номер версии и номер процедуры, которые определяют тип запрашиваемой клиентом процедуры. В поле идентификатор клиента может быть записан цифровой код клиента, идентификатор группы или вообще ничего. Поле верификатор используется при пересылке зашифрованных сообщений. Формат параметров процедуры зависит от типа этой процедуры. Размер поля параметров равен длине UDP-дейтограммы минус сумма длин остальных полей, включая верификатор. В случае работы с TCP-сегментами, где длина пакета не определена, между TCP-заголовком и XID вводится 4-x октетное поле длины RPC-сообщения. Формат RPC-отклика для UDP-версии (Рис. 4.5.16.3):
Рис. 4.5.16.3. Формат RPC-отклика
Поле отклик, содержащее 1, указывает на то, что данное сообщение представляет собой отклик на поступивший ранее запрос. Поле статус содержит 0 в случае, если запрос воспринят. Запрос игнорируется при конфликте кодов RPC-версии или неудачной идентификации клиента. Поле флаг результата принимает значение 0 при успешной обработке запроса. Ненулевое значение этого поля указывает на ошибку.
Для записи параметров RPC-запросов, откликов, параметров и результатов выполнения процедуры используется внешнее представление данных (XDR – External Data Representation, RFC-1014). Отправитель, формируя RPC-сообщение, использует XDR-формат, а получатель преобразует данные из этого формата в традиционное представление.
Существует два базовых вида отклика: MSG_ACCEPTED (сообщение принято) и MSG_DENIED (не принято). Факт приема сообщения не означает выполнение запрошенных процедур, поэтому клиенту выдается дополнительная информация о результатах взаимодействия его запроса с удаленной системой. RPC может найти применение при построении больших распределенных информационных систем, баз данных и систем управления. XDR позволяет программисту избежать написания специальных программ преобразования. Например, в разных ЭВМ используются различные форматы представления чисел с плавающей запятой. XDP берет на себя согласование форматов и делает написание прикладных программ машинно-независимым.
Программы RPC- сервера используют большое число портов с нестандартизованными номерами. Для управления использованием этих портов имеется специальная программа (portmapper), которая имеет номер 100000, номер версии -2 и сама пользуется портом номер 111. Распределение номеров портов можно посмотреть с помощью программы:
/usr/etc/rpcinfo -p
Таблица 4.5.16.1. Коды программ, используемых в NFS
| Назначение программы | Номер программы | Номер версии | Номер процедуры |
| Менеджер портов (port mapper) | 100000 | 2 | 4 |
| NFS | 100003 | 2 | 15 |
| Монтировщик | 100005 | 1 | 5 |
| Менеджер блокировки | 100021 | 1,2,3 | 19 |
| Статус-монитор | 100024 | 1 | 6 |
/p> Монтировщик вызывается NFS-клиентом для обеспечения доступа к файловой системе сервера. Взаимодействие с файловой системой производится с помощью указателей файлов (handle), которые для версии 2 требуют 32 байт, а для версии 3 - 64 байт. Хотя NFS с самого начала была сориентирована на применение UDP (что было оправдано для локальных сетей), в настоящее время она в равной мере использует и TCP. Это позволяет NFS работать уже в масштабе всего Интернет. Третья версия NFS предполагает увеличение числа байт на одну команду READ или WRITE с 8192 до 65535 (ограничение, связанное с размером IP-дейтограммы). Увеличена в третьей версии и предельная длина файлов, которая задается уже 64-, а не 32-битным числом.
RLOGIN
(RFC-1281) - процедура удаленного доступа, реализованная в 4BSD UNIX. RLOGIN позволяет администратору сети определить список ЭВМ, авторизация и доступ к которым является общими. Пользователь может организовать групповой доступ к разным ЭВМ, где он авторизован, сохраняя для себя возможность общения с любой из машин, не вводя каждый раз пароль. Одной из реализаций RLOGIN является RSH. RSH включает в себя интерпретатор команд. Форма обращения имеет вид: RSH имя_ЭВМ команда. RLOGIN позволяет взаимодействовать как с внутренними, так и с внешними ресурсами сети и с этой точки зрения предоставляет большие возможности чем Telnet.
REXECD
представляет собой резидентную управляющую программу (демон), которая позволяет исполнять команды на удаленной ЭВМ в рамках TCP/IP сетей. Команда, выданная одной ЭВМ, может быть выполнена на другой ЭВМ, при этом автоматически, если необходимо, осуществляется процедура авторизации. REXECD использует TCP в качестве транспортной среды. Существуют реализации для сред UNIX, AIX и DOS.
NetBIOS
4.2.3 NetBIOS
Семенов Ю.А. (ГНЦ ИТЭФ)
ftp://ietf.org/internet-drafts/draft-ietf-pppext-netbios-fcp-08.txt) создан для использования группой ЭВМ, поддерживает как режим сессий (работа через соединение), так и режим дейтограмм (без установления соединения). 16-и символьные имена объектов в netbios распределяются динамически. netbios имеет собственную dns, которая может взаимодействовать с интернетовской. Имя объекта при работе с NETBIOS не может начинаться с символа *.
Приложения могут через netbios найти нужные им ресурсы, установить связь и послать или получить информацию. NETBIOS использует для службы имен порт - 137, для службы дейтограмм - порт 138, а для сессий - порт 139.
Любая сессия начинается с netbios-запроса, задания ip-адреса и определения tcp-порта удаленного объекта, далее следует обмен NETBIOS-сообщениями, после чего сессия закрывается. Сессия осуществляет обмен информацией между двумя netbios-приложениями. Длина сообщения лежит в пределах от 0 до 131071 байт. Допустимо одновременное осуществление нескольких сессий между двумя объектами.
При организации IP-транспорта через NETBIOS IP-дейтограмма вкладывается в NETBIOS-пакет. Информационный обмен происходит в этом случае без установления связи между объектами. Имена Netbios должны содержать в себе IP-адреса. Так часть NETBIOS-адреса может иметь вид, ip.**.**.**.**, где IP указывает на тип операции (IP через Netbios), а **.**.**.** - ip-адрес. Система netbios имеет собственную систему команд (call, listen, hang up, send, receive, session status, reset, cancel, adapter status, unlink, remote program load) и примитивов для работы с дейтограммами (send datagram, send broadcast datagram, receive datagram, receive broadcast datagram). Все оконечные узлы netbios делятся на три типа:
Широковещательные ("b") узлы;
узлы точка-точка ("p");
узлы смешанного типа ("m").
IP-адрес может ассоциироваться с одним из указанных типов. B-узлы устанавливают связь со своим партнером посредством широковещательных запросов. P- и M-узлы для этой цели используют netbios сервер имен (NBNS) и сервер распределения дейтограмм (NBDD).
В настоящее время (1985 г) разработана улучшенная версия протокола NETBIOS - NetBeui (NetBios extended user interface). Этот новый протокол используется операционными системами LAN manager, LAN server, Windows for Workgroups и Windows NT, а по своей функции занимает нишу протоколов TCP/IP, охватывая связной, сетевой и транспортный уровни. Здесь стандартизован формат пакетов NetBios, добавлены некоторые новые функции. netbuei базируется на протоколе OSI LLC2, вводит стандарт на формат кадра netbios (NDF) и использует NetBios в качестве интерфейса высокого уровня. Протокол обладает высоким быстродействием и служит для объединения небольших локальных сетей (20-200 ЭВМ) друг с другом или с главной ЭВМ. Этот протокол соответствует связному, сетевому и транспортному уровню модели OSI. В новых версиях NetBuei (3.0 и выше) снято ограничение на число одновременных сессий (254). Среди ограничений NetBuei следует назвать отсутствие внутренней маршрутизации и серьезные ограничения при работе в региональных сетях. По этой причине netbuei рекомендуется для локальных сетей (здесь они предпочтительнее других протоколов), а для внешних связей использовать, например, TCP/IP.
Для подключения терминальной системы к локальной сети или к другой терминальной системе разработан протокол NBFCP (NetBios frames control protocol, код поля протокола = 803F), который в свою очередь базируется на протоколе PPP.
Формат кадра протокола NBFCP показан на рис. 4.2.3.1.
Рис. 4.2.3.1. Формат кадра NBFCP
Поле тип содержит код 2, поле длина определяет размер заголовка, если длина=8, имя партнера отсутствует. Поле класс партнера идентифицирует тип системы отправителя (см. таблицу 4.2.3.1). Таблица возможных значений поля класс партнера приведена ниже. Поле имя партнера может иметь до 32 октетов.
Таблица 4.2.3.1 Коды класса партнера
Код класса
Описание
Протокол WINS разработан компанией MicroSoft для операционной среды Windows и предназначен для расширения возможностей NetBIOS.
WINS-запросы обычно транспортируются в UDP-дейтограммах. При этом используется порт отправителя=137. В поле данных размешается 2-октетное поле идентификатора, позволяющего связать запрос с откликом. Далее следует 2 байта флагов, в случае запроса туда записывается 0. За ним размещается два октета, содержащие число вопросов, 2 октета числа ответов и еще 4 нулевых октетов. Завершается кадр запроса двумя октетами поля типа (00 21 -> статус узла NetBIOS) и полем класса (для Интернет 00 01 -> (IN,1)). Такие запросы позволяют получить дополнительные данные (имя узла, его MAC-адрес, NetBIOS-имя, имя группы) об ЭВМ с заданным IP-адресом. Причем эта ЭВМ может находиться где угодно в Интернет, но непременно работать в OS Windows. Формат поля данных UDP-дейтограммы запроса показан на рис. 1.
Рис. 4.2.3.2. Формат запроса WINS
В поле данных UDP-дейтограммы отклика располагается 2-байтовое поле идентификатора, аналогичного содержащемуся в пакете запроса. Далее следует поле флагов с длиной в два октета. Формат поля данных UDP-дейтограммы отклика показан на рис. 2.
Рис. 4.2.3.2. Формат отклика WINS
Поле флаги имеет следующую структуру:
|
0 _ _ _ |
_ _ _ _ |
Команда |
|
_ 000 |
0 _ _ _ |
Запрос |
|
_ _ _ _ |
_ _ 0 _ |
Не укорочено |
|
_ _ _ _ |
_ _ _ 0 |
Рекурсия нежелательна |
|
_ _ _ _ |
_ _ _ 0 |
Рекурсия нежелательна |
|
1_ _ _ |
_ _ _ _ |
Отклик |
|
_ 000 |
0 _ _ _ |
Запрос |
|
_ _ _ _ |
_ _ 0 _ |
Не укорочено |
|
_ _ _ _ |
_ 1 _ _ |
Официальный ответ |
|
0_ _ _ |
_ _ _ _ |
Уникальное имя NetBIOS |
|
_ 10 _ |
_ _ _ _ |
Узел М-типа |
|
_ _ _ _ |
_ 1 _ _ _ |
Активное имя |
|
_ _ _ _ |
_ _ 0_ |
Временное имя |
/p> Для поля флагов имени группы характерно следующее назначение бит
|
1 _ _ _ |
_ _ _ _ |
Имя группы NetBIOS |
|
_ 10 _ |
_ _ _ _ |
Узел М-типа |
|
_ _ _ _ |
_ 1 _ _ _ |
Активное имя |
|
_ _ _ _ |
_ _ 0_ |
Временное имя |
Одной из наиболее сложных систем
4.4.13.2 Нотация ASN.1
Семенов Ю.А. (ГНЦ ИТЭФ)
Используемая в документах нотация легко читаема и понимаема, а в компактном кодовом представлении информация может использоваться коммуникационными протоколами. Неотъемлемой частью ASN.1 являются базовые правила кодирования BER (Basic Encoding Rules), которые позволяют определить большое разнообразие типов данных. BER описывает то, как представить или закодировать любую величину в рамках стандарта ASN.1. Практически все величины здесь представляются в виде последовательности 8-битных октетов. Восьмой бит октета всегда считается самым старшим. BER позволяет закодировать величину более чем одним способом. Имеется также поднабор правил кодирования DER (Distinguished Encoding Rules, описаны в документе Х.509), которые определяют однозначные способы кодирования величин ASN.1.
Ниже приведены базовые правила обозначений метасинтаксиса ASN.1.
n
[]
{}
|
…
(
многоточие,
напечатанное полужирным шрифтом) обозначает повторения.
=
Все типы ASN.1 кроме CHOICE и ANY имеют метки, которые состоят из класса и неотрицательного кода метки. Типы ASN.1 тождественны, если их числовые метки совпадают. Существует четыре класса меток.
| universal | для типов, значения которых является неизменным для всех приложений. Эти типы определены в документе Х.208. |
| application | для типов со значением, специфическим для приложений, таких как служба каталогов Х.500. Типы двух разных приложений могут иметь одну и ту же метку и разные значения. |
| private | для типов, которые являются специфическими для данного предприятия. |
| content-specific | для типов со значением, специфическим для данного структурного типа. |
Таблица 4.4.13.2.1. Типы и их метки
| Тип | Комментарий | Цифровая метка (шестнадцатеричное) |
| INTEGER | Любое целое число | 02 |
| BIT STRING | Произвольная строка бит | 03 |
| OCTET STRING | Произвольная последовательность октетов | 04 |
| NULL | 0 | 05 |
| OBJECT IDENTIFIER | Последовательность целых компонент, идентифицирующих объект | 06 |
| SEQUENCE and SEQUENCE OF | 10 | |
| SET and SET OF | 11 | |
| PrintableString | Последовательность печатных символов | 13 |
| IA5String | Произвольная строка символов IA5 (ASCII) | 16 |
| UTCTime | Универсальное время (по Гринвичу; GMT) | 17 |
В SMI (Structure of Management Information) не используется полный набор типов объектов, предусмотренный в ASN.1, разрешены только следующие типы примитивов: INTEGER, OCTET STRING, OBJECT IDENTIFIER и NULL.
Стандарт ASN.1 определяет форму представления информации и имен. Для строчных типов может быть введено ограничение на максимальный размер. В ASN.1 определено четыре структурированных типов:
| SEQUENCE | упорядоченный набор из одного или более типов. |
| SEQUENCE OF | упорядоченный набор из нуля или более представителей данного типа. |
| SET | неупорядоченный набор из одного или более типов. |
| SET OF | неупорядоченный набор из нуля или более представителей данного типа. |
/p> Структурированные типы могут иметь опционные компоненты, в том числе со значениями по умолчанию.
Существуют типы помеченные явно и неявно. Неявно помеченные типы получаются из других типов путем изменения метки. Для неявной пометки используется ключевое слово IMPLICIT. Явно помеченные типы получаются из других типов путем добавления внешней метки. Помеченный явно тип – это структурированный тип, состоящий из одного компонента основного типа. Для явной пометки используется ключевое слово EXPLICIT. Пометка (тэгирование) весьма удобна для различия типов в пределах одного приложения.
Тип CHOICE обозначает объединение одного или более альтернатив. Тип ANY служит для обозначения произвольной величины для произвольного типа.
Правила BER определяют один или более способов представить любую величину в виде строки октетов. Существует три метода кодирования величин (в рамках BER): примитивный с известной длиной; конструктивный при известной длине и конструктивный при неизвестной длине. Выбор метода зависит от типа величины и от того, известна ли длина преобразуемой величины. Для простых не строчных типов используется примитивный метод кодирования. В каждом методе BER-кодирование имеет три или четыре части:
| Identifier octets | Определяет класс и числовую метку значения, а также указывает, является ли метод примитивным или конструктивным. |
| Length octets | Для методов кодирования с известной длиной определяет число октетов содержимого. |
| Contents octets | Для примитивных методов с заданной длиной дает конкретное выражение значения. |
| End-of-contents octets | Для конструктивных методов с неопределенной длиной указывает на конец содержимого. |
Этот метод применим для простых типов и типов полученных из простых типов путем неявной пометки. Здесь необходимо, чтобы длина величины была известна заранее. Октеты идентификатора имеют два формата: для числовых меток от 0 до 31, и для числовых меток более 31. В первом случае биты 7 и 8 определяют класс (см. таблицу 4.4.13.2.2), бит 6 равен нулю, указывая на то, что метод кодирования primitive. Остальные биты используются для записи кода числовой метки. Во втором случае используется два или более октетов. В первом октете кодировка аналогична первому варианту за исключением того, что биты 1-5 содержат единицы.
Таблица 4.4.13.2.2. Коды классов
| Класс | Бит 8 |
Бит 7 |
| Универсальный | 0 | 0 |
| Прикладной | 0 | 1 |
| Контекстно-ориентированный | 1 | 0 |
| Частный | 1 | 1 |
Конструктивный метод с заданной длиной
Этот метод используется для простых строчных и структурированных типов, типов, производных от простых строчных типов, и некоторых других. Здесь октеты идентификатора и октеты длины имеют формат, идентичный используемому примитивным методом, за исключением того, что бит 6 первого октета идентификатора равен 1.
Конструктивный метод кодирования с незаданной длиной
Метод используется для простых строчных типов, структурированных типов и типов, полученных из простых и структурированных типов с помощью неявной пометки. Октеты идентификатора идентичны предшествующему. Октет длины содержит код 80. Два октета конца содержательной части содержат 00 00.
Нотация типов, помеченных неявно, имеет вид:
[[class] number] IMPLICIT Type
class = UNIVERSAL | APPLICATION | PRIVITE
где Type – тип, class – опционное имя класса и number – цифровая метка (неотрицательное целое число).
Если имя класса отсутствует, тогда метка является контекстно-ориентированной. Такие метки могут появляться только в структурных компонентах или в типе CHOICE. Например:
PrivateKeyInfo ::= SEQUENCE {
version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKey PrivateKey,
attributes [0] IMPLICIT Attributes OPTIONAL }
Здесь исходным (порождающим) типом является Attributes, класс отсутствует (т.е. контекстно-ориентированный), а числовая метка равна нулю. Кодирование компоненты attributes величины PrivateKeyInfo осуществляется следующим образом.
Октеты идентификатора равны 80, если значение порождающей величины Attributes имеет конструктивное BER-кодирование. Октеты длины и содержимого строго соответствуют октетам порождающей величины Attributes.
Непосредственная (явная) пометка используется для опционных компонент SEQUENCE c порождающим типом ANY и для компонент version типа Certificate
(X.509 и RFC-1114). Нотация типов, помеченных явно, имеет формат.
[ [class] number] EXPLICIT Type
class = UNIVERSAL | APPLICATION | PRIVATE
где Type – тип, class – опционное имя класса, а number – числовая метка в пределах класса (неотрицательное целое число). Пример:
ContentInfo ::= SEQUENCE {
ContebtType ContentType,
Content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
Тип ContentInfo имеет опционную компоненту content с явной контекстно-ориентированной меткой. Здесь порождающим типом является ANY DEFINED BY contentType, класс отсутствует, а числовая метка в пределах класса равна 0.
Другим примером может являться тип Certificate [X.509], имеющий компоненту с явной контекстно-ориентированной меткой (ключевое слово EXPLICIT опущено).
Certificate ::= …
Version [0] Version DEFAULT v1988,
…
BER-кодирование величин, помеченных явно, является всегда конструктивным. Октеты содержимого идентичны соответствующим октетам порождающей величины. Например, BER-кодирование компоненты content величины ContentInfo имеет следующий вид.
Октеты идентификатора равны нулю, Октеты длины представляют длину BER-кодирования порождающей величины ANY DEFINED BY contentType.
Тип ANY
Тип ANY обозначает произвольную величину произвольного типа, где произвольный тип возможно определен при регистрации идентификатора объекта или является целочисленным индексом. Нотация типа ANY имеет формат:
ANY [DEINED BY identifier]
где identifier – опционный идентификатор. Форма ANY DEINED BY identifier может появиться только в компоненте типа SEQUNCE или SET, для которой identifier определяет какую-то другую компоненту и эта компонента имеет тип INTEGER или OBJECT IDENTIFIER. В этой форме истинный тип задается величиной этой другой компоненты. Например, тип AlgorithmIdentifier [X.509] имеет компоненту типа ANY:
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameter ANY DEFINED BY algorithm OPTIONAL }
Здесь истинный тип компоненты parameter зависит от величины компоненты algorithm. Истинный тип будет определен при регистрации объекта величины идентификатора длякомпоненты algorithm.
Битовые строки
Тип BIT STRING обозначает произвольные битовые последовательности произвольной длины (включая ноль). Тип BIT STRING используется для цифровых сигнатур типа ExtendedCertificate или Certificate [X.509]. Нотация BIT STRING имеет формат.
BIT STRING
Например, тип SubjectPublicKeyInfo имеет компоненту типа BIT STRING:
SubjectPublicKeyInfo ::= SEQUENCE {
Algorithm AlgorithmIdentifier,
PublicKey BIT STRING }
BER-кодирование величины BIT STRING может быть примитивным или конструктивным. При примитивном кодировании первый октет содержимого несет в себе длину битовой строки в октетах. В последующих октетах записывается сама битовая последовательность. Процедура кодирования может включать в себя дополнение битовой строки до целого числа октетов нулями (если это необходимо). Строка делится на октеты.
При конструктивном кодировании октеты содержимого представляют собой соединение последовательности субстрок, только последняя из которых содержит код длины, выраженный в октетах. Например, при BER-кодировании значения BIT STRING “0111 1101 1001 1111 11” может быть представлена в одном из следующих видов, в зависимости от выбора схемы дополнения до целого числа октетов, от формата октетов длины и от метода кодирования примитивный/конструктивный).
| 03 04 06 7D 9F C0 | DER-кодирование |
| 03 04 06 7D 9F E0 | Дополнение кодом “100000” |
| 03 81 04 06 7D 9F C0 | Длинная форма представления октетов длины |
|
23 09 03 03 00 7D 9F 03 02 06 C0 |
Конструктивное кодирование “01111101 1001 1111” +”11” |
Тип CHOICE
Этот тип служит для объединения одной или более альтернатив. Нотация типа CHOICE имеет формат.
CHOICE {
[identifier1] Type1,
…,
[identifiern] Typen }
где identifier1, …, identifiern являются опционными идентификаторами альтернатив, а типы Type1, …, Typen – альтернативы. Идентификаторы нужны для документирования и не играют какой-либо роли при кодировании. Типы должны иметь определенные метки. Рассмотрим пример типа ExtendedCertificateOrCertificate, который относится к типу CHOICE.
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate, -- X.509 certificate
extendedCertificate [0] IMPLICIT ExtendedCertificate }
Здесь идентификаторами для альтернатив являются certificate и extendedCertificate, а сами альтернативы представлены типами Certificate и [0] IMPLICIT ExtendedCertificate. BER-кодирование для типа CHOICE сводится к кодированию альтернатив. При этом октеты идентификатора для рассмотренного примера содержат код 30, если выбранная альтернатива certificate, и A0 – в случае ExtendedCertificate.
Строки IA5
Тип IA5String представляет любые последовательности IA5-символов (международный алфавит 5 – эквивалентно ASCII). Длина строки может быть любой, включая нуль. Этот тип используется для адресов электронной почты и неструктурированных имен. Нотация типа IA5String имеет простой формат.
IA5String
BER-кодирование величины IA5String может быть примитивным или структурированным. При примитивном кодировании октеты содержимого представляют собой символы IA5 в ASCII-кодов. При конструктивном кодировании октеты содержимого представляют собой соединение ряда IA5-субстрок. Рассмотрим примеры представления значения IA5-строки “test1@rsa.com”.
| 12 0D 74 65 73 74 31 40 72 73 61 2E 63 6F 6D | DER-кодирование |
| 12 81 0D 74 65 73 74 31 40 72 73 61 2E 63 6F 6D | Длинная форма октетов длины |
| 32 13 12 05 74 65 73 74 31 12 01 40 12 07 72 73 61 2E 63 6F 6D |
Конструктивное кодирование: “test1” + “@” + “rsa.com” |
Целое
Тип INTEGER представляет любые целые числа (положительные, отрицательные или 0). Тип INTEGER используется для номеров версий, криптографических параметров (показателей, модулей) и типов RSAPublicKey, RSAPrivatKey, DHParameter PBEParameter. Нотация типа INTEGER имеет формат:
INTEGER [{identifier1(value1) … identifiern(valuen) }]
где identifier1 … identifiern являются опционными идентификаторами, а value1… valuen опционные целые значения. Например, Version RFC-1114 относится к целому типу со значением:
Version ::= INTEGER { 1988(0) }
Идентификатору v1988 поставлено в соответствие значение 0. Тип Certificate RFC-1114 использует идентификатор v1988для присвоения значения по умолчанию компоненту version:
Certificate
version Version DEFAULT v1988,
…
BER-кодирование значения INTEGER является всегда примитивным. Октеты содержимого представляют значение целого по модулю 256 в форме дополнения по модулю 2. Старшая цифра является первой. Значение нуль кодируется одним октетом 00. Примеры BER-кодирования (совпадающего в данном случае с DER-кодированием) представлены в таблице 4.4.13.2.3.
Таблица 4.4.13.2.3. Примеры BER-кодирования
| Значение целого | BER-код |
| 0 | 02 01 00 |
| 127 | 02 02 00 7F |
| 128 | 02 02 00 80 |
| 256 | 02 02 01 00 |
| -128 | 02 01 80 |
| -129 | 02 02 FF 7F |
Тип NULL обозначает нулевую величину и предназначен для использования в качестве параметра алгоритмов. Нотация для типа NULL имеет формат:
NULL
Кодирование для типа NULL является всегда примитивным, октеты содержимого пусты. Например, BER-представление значения NULL может иметь одну из приведенных ниже форм (зависит от используемого представления октетов длины).
05 00
05 81 00
DER-кодирование типа NULL является также примитивным и совпадает с первой строкой приведенного выше примера.
Объектные идентификаторы
Тип OBJECT IDENTIFIER служит для обозначения дентификаторов, которые представляют собой последовательность целочисленных компонент, которые идентифицируют такие объекты, как алгоритм или атрибут имени каталога. Значение OBJECT IDENTIFIER может содержать любое число неотрицательных компонент. Этот тип не относится в числу строчных. Значения OBJECT IDENTIFIER присваиваются при регистрации.
Тип OBJECT IDENTIFIER используется для идентификации содержимого ContentInfo, алгоритмов в X.509 (AlgorithmIdentifier) и атрибутов Attribute и AttributeValueAssertion (X.501). Нотация OBJECT IDENTIFIER имеет формат.
OBJECT IDENTIFIER
Нотация величины OBJECT IDENTIFIER имеет вид:
{ [identifier] component1… componentn}
componenti = identifieri | identifieri
(valuei) | valuei
где identifier, identifier1, … identifiern являются идентификаторами, а value1 …, valuen – опционные целые числа. Идентификаторы без целых значений могут встретиться только для объектов, описанных в Х.208.
Например, нижеприведенные величины объектных идентификаторов присвоены RSA DATA Security, Inc.
{ iso(1) member-body(2) 840 113549 }
{ 1 2 840 113549 }
В таблице 4.4.13.2.4 представлены некоторые объектные идентификаторы и их значения.
Таблица 4.4.13.2.4. Некоторые объектные идентификаторы и их значения
| Величина объектного идентификатора | Назначение |
| { 1 2 } | Члены ISO |
| { 1 2 840 } | US (ANSI) |
| { 1 2 840 113549} | RSA Data Security, Inc. |
| { 1 2 840 113549 } | RSA Data Security, Inc. PKCS (Public Key Cryptography Standard) |
| { 2 5 } | Служба каталогов (X.500) |
| { 2 5 8 } | Служба каталогов - алгоритмы |
Первый субидентификатор равен 40value1
+ value2. (значение value1 лежит в пределах 0-2 включительно, а value2 в интервале 0-39, когда value1 равна 0 или 1.
i-ый субидентификатор равен valuei+1 ; 2 Ј iЈ n-1.
Например, субидентификаторы объектного идентификатора RSA Data Security, Inc. равны 42 = 40ґ 1 + 2, 840, 113549 и 1. В шестнадцатеричном представлении BER-код этого объектного идентификатора имеет вид:
06 07 2A 86 48 86 F7 0D 01
DER-кодирование в данном случае совпадает с BER.
Строки октетов
Тип OCTET STRING служит для представления произвольных последовательностей октетов. Значение OCTET STRING может иметь любую длину, включая нуль. OCTET STRING используется для представления сообщений, включая зашифрованные, а также для типа PBEParameter. Нотация типа OCTET STRING имеет формат.
OCTET STRING [SIZE ({size | size1..size2})]
где size, size1 и size2 опционные ограничения размера. В форме OCTET STRING SIZE(size) строка октетов должна иметь октеты size. В формате OCTET STRING SIZE(size1 .. size2) строка должна содержать число октетов между size1 и size2. Например, тип PBEParameter имеет компоненту типа OCTET STRING:
PBEParameter ::= SEQUENCE {
salt OCTET STRING SIZE (8),
iterationCount INTEGER }
Здесь размер компоненты salt всегда равен 8 октетам. BER-кодирование типа OCTET STRING может быть примитивным или конструктивным. При примитивном кодировании октеты содержимого несут в себе октеты строки с первого по последний. При конструктивном кодировании содержимое октетов представляет собой последовательное объединение субстрок значения OCTET STRING. Например, BER-код значения OCTET STRING 01 23 45 67 89 AB CD EF может иметь один из следующих видов, в зависимости от формата октетов длины и вида кодирования (примитивное/конструктивное).
| 04 08 01 23 45 67 89 AB CD EF | DER-кодирование |
| 04 81 08 01 23 45 67 89 AB CD EF | Длинный формат октетов длины |
| 24 0С | Конструктивное кодирование |
| 04 04 01 23 45 67 | “01 23 45 67” + “89 AB CD EF” |
| 04 04 89 AB CD EF |
Тип PrintableString предназначен для описания произвольных последовательностей печатных символов из набора:
A, B,…,Z
a,b,…,z
0,1,…,9
(пробел) ‘ () +, - . / : = ?
Этот тип используется для представления атрибутов имен (Х.520). Нотация типа PrintableString имеет вид:
PrintableString
BER-кодирование значения PrintableString может быть примитивным или конструктивным. При примитивном кодировании печатных символов байты содержимого несут в себе строки октетов печатных ASCII-кодов. При конструктивном кодировании содержимое октетов представляет собой последовательное объединение субстрок. Например, BER-код значения PrintableString “Test User 1” может быть представлено одним из ниже приведенных способов.
| 13 0B 54 65 73 74 20 55 73 65 72 20 31 | DER-кодирование |
| 13 81 0B 54 65 73 74 20 55 73 65 72 20 31 | Длинная форма октетов длины |
| 33 0F | Конструктивная форма, |
| 13 05 54 65 73 74 20 | “Test” + “User 1” |
| 13 06 55 73 65 72 20 31 |
/p> Тип SEQUENCE
Тип SEQUENCE обозначает упорядоченную последовательность одного или более типов. Нотация типа SEQUENCE имеет вид:
SEQUENCE {
[identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
…,
[identifiern] Typen [{OPTIONAL | DEFAULT valuen}],
где identifier1 , …, identifiern
являются опционными идентификаторами компонентов, Type1 , …, Typen - типы компонентов, а value1 ,…, valuen опционные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что значения компонентов являются опционными. Квалификатор DEFAULT говорит о том, что величина компонента является опционной и ей присваивается определенное значение, если компонент отсутствует. Например, тип Validity [X.509] относится к типу SEQUENCE и имеет два компонента.
Validity ::= SEQUENCE {
start UTCTime,
end UTCTime }
Здесь start и end являются идентификаторами компонент, а типом компонент служит UTCTime. BER-кодирование значения SEQUENCE является всегда конструктивным. Октеты содержимого представляют последовательное объединение BER-кодов значений компонентов последовательности.
Тип SEQUENCE OF
Тип SEQUENCE OF обозначает упорядоченную последовательность из нуля или более компонентов данного типа, используется для имен в X.501. Нотация SEQUENCE OF имеет вид:
SEQUENCE OF Type
Так например, тип RNDSequence состоит из нуля или более компонент типа RelativeDistinguishedName.
RNDSequence ::= SEQUENCE OF RelativeDistinguishedName
BER-кодирование SEQUENCE OF является всегда конструктивным. Октеты содержимого представляют собой объединение BER-кодов значений элементов последовательности в порядке их расположения. DER-кодирование имеет тот же формат.
Тип SET
Тип SET представляет собой неупорядоченное объединение из одного или более типов. Нотация типа SET имеет вид.
SET {
[identifier1] Type1 Type1
[{OPTIONAL | DEFAULT value1}],
…,
[identifiern] Typen [{OPTIONAL | DEFAULT valuen}],
где identifier1 , …, identifiern
являются опционными идентификаторами компонентов, Type1
, …, Typen - типы компонентов, а value1 ,…, valuen
опционные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что значения компонентов являются опционными. Квалификатор DEFAULT говорит о том, что величина компонента является опционной и ей присваивается определенное значение, если компонент отсутствует.
BER-кодирование для типа SET является всегда конструктивным. Октеты содержимого представляют последовательное объединение BER-кодов значений компонентов набора.
Тип SET OF
Тип SET OF представляет неупорядоченный набор, состоящий из нуля или более компонентов заданного типа и предназначенный для атрибутов PKCS (Public-Key Cryptography Standard) и имен X.501. Нотация типа SET OF имеет вид:
SET OF Type
где Type – тип. Так тип RelativeDistinguishedName состоит из нуля или более компонентов типа AttributeValueAssertion.
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
BER-кодирование типа SET OF является всегда конструктивным. Октеты содержимого представляют собой объединение BER-кодов величин компонентов в порядке их исходного расположения. DER-кодирование также является всегда конструктивным, октеты содержимого представляются как и в случае BER-кодировки. Но компоненты лексикографически упорядочиваются.
Тип UTCTime
Тип UTCTime служит для обозначения универсального местного времени с привязкой по Гринвичу (GMT). Значение UTCTime характеризует местное время с точностью минут или секунд и временной сдвиг по отношению к GMT. Оно может иметь следующие формы:
YYMMDDhhmmZ
YYMMDDhhmm+hh`mm`
YYMMDDhhmm-hh`mm`
YYMMDDhhmmssZ
YYMMDDhhmmss+ hh`mm`
YYMMDDhhmmss- hh`mm`
где
| YY | младшие две цифры года |
| ММ | код месяца (01 – 12) |
| DD | код дня (01 – 31) |
| hh | код часа (00 – 23) |
| mm | код минут (00 – 59) |
| ss | код секунд (00 – 59) |
| Z | означает местное время по Гринвичу, + указывает на то, что местное время отстает от GMT, а – указывает на то, что местное время опережает GMT. |
| hh` | абсолютное значение смещения по отношению к GMT в часах |
| mm` | абсолютное смещение по отношению к GMT в минутах. |
/p> UTCTime используется для определения типа Validity [X.509]. Нотация типа UTCTime имеет вид.
UTCTime
BER-кодирование значения UTCTime может быть примитивным или конструктивным. При примитивном кодировании октеты представляют собой символы строки в виде ASCII-кодов. При конструктивном кодировании октеты образуют объединение BER-кодов последовательных субстрок. В качестве примера рассмотрим варианты представления времени 4:45:40 после полудня 6 мая 1991 года (Pacific Daylight Time) в виде величины UTCTime.
“910506164540-0700”
“910506234540Z”
Это представление эквивалентно следующим BER-кодам:
17 0D 39 31 30 35 30 36 32 33 34 35 34 30 5A
17 11 39 31 30 35 30 36 31 36 34 35 34 30 2D 30 37 30 30
DER-кодирование типа UTCTime всегда является примитивным.
Ниже приводится пример ASN.1 нотации имен типа X.501.
Name ::= CHOICE { RNDSequence }
RNDSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
AttributeValueAssertion ::= SEQUENCE { AttributeType, AttributeValue }
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY
Тип Name идентифицирует объект в каталоге X.500. Name имеет тип CHOICE с одной альтернативой RNDSequence. Тип RNDSequence указывает проход по дереву каталогов X.500, начиная с корневой части. RNDSequence имеет тип SEQUENCE OF, состоящий из нуля или более компонентов RelativeDistinguishedName. Тип RelativeDistinguishedName присваивает уникальное имя объекту на дереве каталога. RelativeDistinguishedName имеет тип SET OF, состоящий из нуля или более компонентов AttributeValueAssertion. Тип AttributeValueAssertion присваивает значение атрибуту имени (например, определяющее принадлежность к стране). AttributeValueAssertion имеет тип SEQUENCE, состоящий из двух компонентов AttributeType и AttributeValue. AttributeType идентифицирует атрибут с помощью объектного идентификатора. AttributeValue присваивает значение атрибуту. Ниже предлагается пример DER-кодирования типа Name. В качестве имени использовано RSA Data Security, Inc. NOTARY (отдел Internet Privacy Enhanced Mail).
(root)
|
countryName = ”US”
|
organizationName = ”RSA Data Security, Inc.”
|
organizationalUnitName = ”NOTARY”
Каждый уровень соответствует одному значению RelativeDistinguishedName, в выбранном случае они имеют только одно значение AttributeValueAssertion. Значение AttributeType помещается до знака равенства, а AttributeValue (строка печатных символов с заданным типом атрибута) - после знака равенства.
Тип атрибута
DER-кодирование трех значений AttributeType согласно примитивному методу с заданной длиной дает следующие строки октетов.
| 06 03 55 04 06 | countryName |
| 06 03 55 04 0A | organizationName |
| 06 03 55 04 0B | organizationalUnitName |
AttributeType OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
countryName OBJECT IDENTIFIER ::= { AttributeType 6 }
organizationName OBJECT IDENTIFIER ::= { AttributeType 10 }
organizationalUnitName OBJECT IDENTIFIER ::= { AttributeType 11 }
Октеты идентификатора имеют формат с меткой, так как метка равна 6 для OBJECT IDENTIFIER. Биты 8 и 7 равны 0, указывая на универсальный класс, бит 6 также равен 0, что говорит о примитивном методе кодирования. Октеты длины ориентированы на короткую форму представления. Октеты содержимого представляют собой объединения трех-октетных строк, полученных из субидентификаторов: 85 = 40x2 + 5; 4 и 6, 10 или 11.
Значение атрибута
DER-кодирование трех значений AttributeValue в соответствии с примитивным методом при заданной длине дает следующие строки:
| 13 02 55 53 | “US” |
| 13 17 52 53 41 20 | “RSA |
| 44 61 74 61 20 | Data |
| 53 65 63 75 72 69 74 79 2C 20 | Security, |
| 49 6E 63 2E | Inc.” |
Атрибут ValueAssertion
DER-кодирование трех значений AttributeValueAssertion в соответствии с конструктивным методом дает следующие строки октетов.
| 30 09 06 03 55 04 06 13 02 55 53 |
countryName = “US” |
|
30 1E 06 03 55 04 0A 13 17 52 53 41 20 44 61 74 61 20 53 65 63 75 72 69 74 79 2C 20 49 6E 63 2E |
organizationName = “RSA Data Security, Inc.” |
|
30 0D 06 03 55 04 0B 13 06 4E 4F 54 41 52 59 |
organizationalUnitName = “NOTARY” |
RelativeDistinguishedName/p>
DER-кодирование трех значений RelativeDistinguishedName, выполняемое согласно конструктивному методу, дает следующие строки октетов.
31 0B
| 30 09 … 55 53 |
| 30 1E … 63 2E |
| 30 0D … 52 59 |
RDNSequence
DER-кодирование значений RDNSequence, выполняемое согласно конструктивному методу при заданной длине, дает следующие строки октетов.
30 40
31 0B … 55 53
31 20 … 63 2E
31 0F … 52 59
Октеты идентификатора используют короткий формат (low-octet form), так как для SEQUENCE OF метка равна 16. Биты 8 и 7 равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное кодирование). Октеты длины следуют “короткому” формату, а октеты содержимого представляют собой объединение DER-кодов трех компонент RelativeDistinguishedName в порядке их следования.
Name
DER-кодирование значений Name выполняется аналогично значениям RDNSequence и выдает следующие результаты.
30 40 31 0B
30 09
06 03 55 04 06
13 02 55 53
31 20 30 1E
06 03 55 04 0A
13 17 52 53 41 20 44 61 74 61 20 53 65 63 75 72 69
74 79 2C 20 49 6E 63 2E
31 0F 30 0D
06 03 55 04 0B
13 06 4E 4F 54 41 52 59
Обнаружение ошибок
2.7 Обнаружение ошибок
Семенов Ю.А. (ГНЦ ИТЭФ)
Каналы передачи данных ненадежны, да и само оборудование обработки информации работает со сбоями. По этой причине важную роль приобретают механизмы детектирования ошибок. Ведь если ошибка обнаружена, можно осуществить повторную передачу данных и решить проблему. Если исходный код по своей длине равен полученному коду, обнаружить ошибку передачи не предоставляется возможным.
Простейшим способом обнаружения ошибок является контроль по четности. Обычно контролируется передача блока данных (М бит). Этому блоку ставится в соответствие кодовое слово длиной N бит, причем N>M. Избыточность кода характеризуется величиной 1-M/N. Вероятность обнаружения ошибки определяется отношением M/N (чем меньше это отношение, тем выше вероятность обнаружения ошибки, но и выше избыточность).
При передаче информации она кодируется таким образом, чтобы с одной стороны характеризовать ее минимальным числом символов, а с другой – минимизировать вероятность ошибки при декодировании получателем. Для выбора типа кодирования важную роль играет так называемое расстояние Хэмминга.
Пусть А и Б две двоичные кодовые последовательности равной длины. Расстояние Хэмминга между двумя этими кодовыми последовательностями равно числу символов, которыми они отличаются. Например, расстояние Хэмминга между кодами 00111 и 10101 равно 2.
Можно показать, что для детектирования ошибок в n битах, схема кодирования требует применения кодовых слов с расстоянием Хэмминга не менее N+1. Можно также показать, что для исправления ошибок в N битах необходима схема кодирования с расстоянием Хэмминга между кодами не менее 2N+1. Таким образом, конструируя код, мы пытаемся обеспечить расстояние Хэмминга между возможными кодовыми последовательностями больше, чем оно может возникнуть из-за ошибок.
Широко распространены коды с одиночным битом четности. В этих кодах к каждым М бит добавляется 1 бит, значение которого определяется четностью (или нечетностью) суммы этих М бит. Так, например, для двухбитовых кодов 00, 01, 10, 11 кодами с контролем четности будут 000, 011, 101 и 110. Если в процессе передачи один бит будет передан неверно, четность кода из М+1 бита изменится.
Предположим, что частота ошибок (BER) равна р=10-4. В этом случае вероятность передачи 8 бит с ошибкой составит 1-(1-p)8=7,9х10-4. Добавление бита четности позволяет детектировать любую ошибку в одном из переданных битах. Здесь вероятность ошибки в одном из 9 бит равна 9p(1-p)8. Вероятность же реализации необнаруженной ошибки составит 1-(1-p)9 – 9p(1-p)8 = 3,6x10-7. Таким образом, добавление бита четности уменьшает вероятность необнаруженной ошибки почти в 1000 раз. Использование одного бита четности типично для асинхронного метода передачи. В синхронных каналах чаще используется вычисление и передача битов четности как для строк, так и для столбцов передаваемого массива данных. Такая схема позволяет не только регистрировать но и исправлять ошибки в одном из битов переданного блока.
Контроль по четности достаточно эффективен для выявления одиночных и множественных ошибок в условиях, когда они являются независимыми. При возникновении ошибок в кластерах бит метод контроля четности неэффективен и тогда предпочтительнее метод вычисления циклических сумм (CRC). В этом методе передаваемый кадр делится на специально подобранный образующий полином. Дополнение остатка от деления и является контрольной суммой.
В Ethernet Вычисление crc производится аппаратно (см. также ethernet). На рис. 2.7.1. показан пример реализации аппаратного расчета CRC для образующего полинома B(x)= 1 + x2 + x3 +x5 + x7. В этой схеме входной код приходит слева.
Рис. 2.7.1. Схема реализации расчета CRC
Эффективность CRC для обнаружения ошибок на многие порядки выше простого контроля четности. В настоящее время стандартизовано несколько типов образующих полиномов. Для оценочных целей можно считать, что вероятность невыявления ошибки в случае использования CRC, если ошибка на самом деле имеет место, равна (1/2)r, где r - степень образующего полинома.
Оптоволоконные каналы
3.2 Оптоволоконные каналы
Семенов Ю.А. (ГНЦ ИТЭФ)
А.Г.Белл в 1880 году запатентовал фотофон – прибор для передачи голоса посредством светового сигнала с селеновым фотодетектором. Первые коммерческие телефонные системы были созданы лишь в 1977 году и работали со скоростью 44,7 Мбит/с. Одномодовые волоконные кабели начали производиться в 1983 году. В 1990 году Линн Моллинер (Bellcore) продемонстрировал передачу данных со скоростью 2,5Гбит/c на расстояние 7500 км (без промежуточных усилителей сигнала) В 1990 году в США суммарная протяженность оптических волокон составляла около 9000000 км. В 2000 году обшая длина оптоволокон только в США превысила 30 миллионов километров. Оптоволоконные линии связи работают в частотном диапазоне 1013 – 1016Гц, что на 6 порядков больше, чем в случае
радиочастотных каналов (это обеспечивает пропускную способность 50000 Гбит/c). Но земная атмосфера является плохой средой для распространения света. По этой причине только разработка кремниевых волокон с низким коэффициентом поглощения в инфракрасном диапазоне (< 0,2 дБ/км) сделало возможным широкое распространение оптических каналов связи. Укладывается ~1000км оптоволоконного кабеля в день. В настоящее время каналы обычно имеют пропускную способность ~1Гбит/c и это связано с ограниченным быстродействием оборудования, преобразующего оптический сигнал в электрический и обратно. В ближайшие годы следует ожидать увеличения быстродействия таких устройств в 100-1000 раз. Учитывая, что
df = (cdl)/l2, где с - скорость света, f - частота, а l - длина волны.
Для наиболее популярного диапазона l = 1,3m и dl = 0,17m мы имеем df = ~30ТГц.
В 2002 году компанией Zonu разработан фототрансивер (GBIC) на 1,25Гбит/c для передачи и приема данных по одному и тому же волокну при длине волны 1310 нм. Для одномодового волокна расстояние передачи может составлять до 10 км. При длине волны 1550 нм достижимо расстояние передачи в 40 км. Разрабатывается вариант для скоростей передачи 2,5Гбит/c
Оптоволоконное соединение гарантирует минимум шумов и высокую безопасность (практически почти невозможно сделать отвод). Пластиковые волокна применимы при длинах соединений не более 100 метров и при ограниченном быстродействии (-10, что во многих случаях делает ненужным контроль целостности сообщений.
При построении сетей используются многожильные кабели (рис. 3.2.1; существуют и другие разновидности кабеля: например, двух- или четырехжильные, а также плоские). В верхней части рисунка [a] изображено отдельное оптоволокно, а в нижней [Б] сечение восьмижильного оптического кабеля. Свет (длина волны l
~ 1350 или 1500 нм) вводится в оптоволокно (диаметром dm) с помощью светоизлучающего диода или полупроводникового лазера. Центральное волокно покрывается слоем (клэдинг, 1А), коэффициент преломления которого меньше чем у центрального ядра (стрелками условно показан ход лучей света в волокне). Для обеспечения механической прочности извне волокно покрывается полимерным слоем (2А). Кабель может содержать много волокон, например 8 (1Б). В центре кабеля помещается стальной трос (3Б), который используется при прокладке кабеля. С внешней стороны кабель защищается (от крыс!) стальной оплеткой (2Б) и герметизируется эластичным полимерным покрытием.
Рис. 3.2.1. Сечение оптоволоконного кабеля
Существует несколько типов оптических волокон, обладающих различными свойствами. Они отличаются друг от друга зависимостью коэффициента преломления от радиуса центрального волокна. На рис. 3.2.2 показаны три разновидности волокна (А, Б и В). Буквами А и Б помечен мультимодовый вид волокон. Тип Б имеет меньшую дисперсию времени распространения и по этой причине вносит меньшие искажения формы сигнала. Установлено, что, придавая световым импульсам определенную форму (обратный гиперболический косинус), дисперсионные эффекты можно полностью исключить. При этом появляется возможность передавать импульсы на расстояние в тысячи километров без искажения их формы. Такие импульсы называются солитонами. При современных же технологиях необходимо использовать повторители через каждые 30 км (против 5 км для медных проводов). По сравнению с медными проводами оптоволоконные кабели несравненно легче. Так одна тысяча скрученных пар при длине 1 км весит 8 тонн, а два волокна той же длины, обладающие большей пропускной способностью, имеют вес 100кг. Это обстоятельство открывает возможность укладки оптических кабелей вдоль высоковольтных линий связи, подвешивая или обвивая их вокруг проводников.
Рис. 3.2.2. Разновидности оптических волокон, отличающиеся зависимостью коэффициента преломления от радиуса
Буквой В помечен одномодовый вид волокна (понятие мода связано с характером распространения электромагнитных волн). Мода представляет собой одно из возможных решений уравнения Максвелла. В упрощенном виде можно считать, что мода – это одна из возможных траекторий, по которой может распространяться свет в волокне. Чем больше мод, тем больше дисперсионное искажение сформы сигнала. Одномодовое волокно позволяет получить полосу пропускания в диапазоне 50-100 ГГц-км. Типовое значение модовой дисперсии лежит в пределах от 15 до 30 нсек/км. Эта разновидность волокна воспринимает меньшую долю света на входе, за то обеспечивает минимальное искажение сигнала и минимальные потери амплитуды. Следует также иметь в виду, что оборудование для работы с одномодовым волокном значительно дороже. Центральная часть одномодового волокна имеет диаметр 3-10 m, а диаметр клэдинга составляет 30-125 m. Число мод, допускаемых волокном, в известной мере определяет его информационную емкость. Модовая дисперсия приводит к расплыванию импульсов и их наезжанию друг на друга. Дисперсия зависит от диаметра центральной части волокна и длины волны света. Число мод n равно для волокна типа А:
где d – диаметр центральной части (ядра), a – численная апертура волокна, а l – длина волны. Волокно с диаметром центральной части волокна 50 m поддерживает 1000 мод. Для волокна типа Б (рис. 3.2.2) значение n в два раза меньше. Численная апертура А равна
Очевидно, что чем больше длина волны, тем меньше число мод и меньше искажения сигнала. Это, в частности, является причиной работы в длинноволновом инфракрасном диапазоне. Но даже для одной и той же моды различные длины волн распространяются по волокну с разной скоростью. Волокно со сглаженным профилем показателя преломления имеет дисперсию 1 нсек/км и меньше. Это, в частности, связано с тем, что свет в перефирийных областях волокна с большей длиной траектории движется быстрее (там ведь меньше коэффициент преломления). Одномодовый режим реализуется тогда, когда длина волны вета становится сравнимой с диаметром ядра волокна. Длина волны, при которой волокно становится одномодовым, называется пороговой. Волокно с диаметром 50 микрон может поддерживать до 1000 мод. В отличие от многомодового волокна, в одномодовом - излучение присутствует не только внутри ядра. По этой причине повышаются требования к оптическим свойствам клэдинга. Для многомодового волокна требования к прозрачности клэдинга весьма умеренны. Затуханием обычно называется ослабление сигнала по мере его движения по волокну. Оно измеряется в децибелах на километр и варьируется от 300 дБ/км для пластиковых волокон до 0,21 дБ/км – для одномодовых волокон. Полоса пропускания волокна определяется дисперсией. Приближенно полосу пропускания одномодового волокна можно оценить согласно формуле.
BW = 0,187/(Disp*SW*L),
где Disp – дисперсия на рабочей длине волны в сек на нм и на км;
SW - ширина спектра источника в нм;M
L - длина волокна в км;
Если диаметр источника света не соответствует диаметру ядра волокна, то потери света, связанные с геометрическим рассогласованием могут быть охарактеризованы следующей формулой.
Потеридиам = 10log10(Диаметрволокна/Диаметристочника)2
Потерь нет, когда волокно имеет диаметр больше диаметра источника света. Если числовая апертура источника больше апертуры волокна, то потери света составят:
Потеридиам = 10log10(Aволокна/Aисточника)2
Помимо дисперсии быстродействие оптического канала ограничивается шумами. Шумы имеют две составляющие: дробовой и тепловой шум. Дробовой шум определяется соотношением:
isn2= 2eiB,
где е – заряд электрона, i – средний ток, протекающий через приемник, и В – ширина полосы пропускания приемника. Типовое значение дробового шума составляет 25 нА при температуре 25 градусов Цельсия. Тепловой шум характеризуется соотношением:
isn2=(4kTB)/RL
где k – постоянная Больцмана, Т – температура по шкале Кельвина, В – ширина полосы пропускания приемника, RL - сопротивление нагрузки. При полосе в 10 МГц и температуре 298 0К эта составляющая шума равна 18 нА. Одной из составляющих теплового шума является темновой ток, который возрастает на 10% при росте температуры на 1 градус.
Чувствительность приемника задается квантовой эффективностью, которая характеризует отношение числа первичных электронно-дырочных пар к числу падающих на детектор фотонов. Этот параметр часто выражается в процентах (реже в амперах на люмен). Так, если на каждые 100 фотонов приходится 60 пар электрон-дырка, то квантовая эффективность равна 60%. Чувствительность фотодетектора R может быть вычислена на основе квантовой чувствительности. R= (nel)/hc, где е – заряд электрона, h – постоянная Планка, с – скорость света l - длина волны, а n - квантовая чувствительность.
Источники излучения инжектируемого в волокно имеют конечную полосу частот. Так светоизлучающие диоды излучают свет с шириной полосы 35 нм, а лазеры 2-3 нм (лазеры имеют, кроме того, более узкую диаграмму направленности, чем диоды). Характеристики светодиодов и инжекционных лазерных диодов приведены в таблице 3.2.1.
Таблица 3.2.1. Характеристики светодиодов и инжекционных лазерных диодов
Таблица 3.2.2. Характеристики оптических приемников
| Параметры | pin | Лавинный фотодиод | Фототранзистор | Фотоприемник Дарлингтона |
| Чувствительность | 0,5 мкa/мкВт | 15 мкa/мкВт | 35 мкa/мкВт | 180 мкa/мкВт |
| Время нарастания | 1 нс | 2 нс | 2 мкс | 40 мкс |
| Напряжение смещения | 10 В | 100 В | 10 В | 10 В |
Рис. 3.2.3. Зависимость поглощения света в волокне от длины волны
Из рисунка видно, что минимумы поглощения приходятся на 1300 и ~1500 нм, что и используется для целей телекоммуникаций. При длине волны 1300 нм дисперсия скоростей распространения различных длин волн минимальна. Диапазон ~850 нм характеризуется высоким поглащением, но он привлекателен тем, что как лазеры, так и электроника могут быть изготовлены из одного материала (арсенида галлия). Используемые оптические диапазоны выделены зеленым цветом. Зависимость дисперсии от длины волны показана на рис. 3.2.4.
Рис. 3.2.4. Зависимость дисперсии от длины волны
Из рисунка видно, что в области ниже 1300 нм более длинные волны движутся быстрее коротких. Для длин волн >1300нм имеет место обратная ситуация – более длинные волны движутся медленнее коротких. Для одномодовых волокон определяющий вклад в искажения вносится дисперсией скоростей распространения, для многомодовых основной вклад вносит модовая дисперсия. Зависимость полосы пропускания волокна от его длины приведена на рис. 3.2.5.
Рис. 3.2.5. Зависимость полосы пропускания волокна от его длины
Типовые характеристики оптических волокон приведены в таблице 3.2.3. (См. также Дональд Дж. Стерлинг, Волоконная оптика. Техническое руководство. Изд. “ЛОРИ, Москва, 1998 а также Дж. Гауэр, Оптические системы связи. Москва, “Радио и связь”, 1989)
Таблица 3.2.3. Типовые характеристики оптических волокон
| Тип волокна |
Диаметр ядра [мкм] |
Диаметр клэдинга [мкм] |
А |
Затухание [дБ/км] |
Полоса пропускания [МГц/км] | ||
| Длина волны | 850 |
1300 |
1550 |
||||
| Одномодовое |
9,3 8,1 |
125 125 |
0,13 0,17 |
0,4 0,5 |
0,3 0,25 |
5000 для 850 нм | |
| Со сглаженным индексом |
50 62,5 85 |
125 125 125 |
0,2 0,275 0,26 |
2,4 3,0 2,8 |
0,6 0,7 0,7 |
0,5 0,3 0,4 |
600 для 850 нм; 1500 для 1300 нм |
| Ступенчатый индекс | 200 | 380 | 0,27 | 6,0 | 6 при 850 нм |
Соединители для оптических волокон имеют обычно конструкцию, показанную на рис. 3.2.6, и изготовляются из керамики. Потеря света в соединителе составляет 10-20%. Для сравнения сварка волокон приводит к потерям не более 1-2%. Существует также техника механического сращивания волокон, которая характеризуется потерями около 10% (splice). Оптические аттенюаторы для оптимального согласования динамического диапазона оптического сигнала и интервала чувствительности входного устройства представляют собой тонкие металлические шайбы, которые увеличивают зазор между волокном кабеля и приемником.
Рис. 3.2.6. Схема оптического разъема
С использованием оптических волокон можно создавать не только кольцевые структуры. Возможно построение фрагмента сети, по характеру связей эквивалентного кабельному сегменту или хабу. Схема такого фрагмента сети представлена на рис. 3.2.7 (пассивный хаб-концентратор). Базовым элементом этой субсети является прозрачный цилиндр, на один из торцов которого подключаются выходные волокна всех передатчиков интерфейсов устройств, составляющих субсеть. Сигнал с другого торца через волокна поступает на вход фото приемников интерфейсов. Таким образом, сигнал, переданный одним из интерфейсов, поступает на вход всех остальных интерфейсов, подключенных к этой субсети. При этом потери света составляют 2С + S + 10*log(N), где С - потери в разъеме, S - потери в пассивном разветвителе, а N - число оптических каналов (N может достигать 64). Современные микросхемы приемо-передатчиков (корпус DIP) имеют встроенные разъемы для оптического кабеля (62,5/125мкм или 10/125 мкм). Некоторые из них (например, ODL 200 AT&T) способны осуществлять переключение на обходной оптический путь (bypass) при отключении питания.
Рис. 3.2.7. Схема пассивного оптоволоконного хаба
В последнее время заметного удешевления оптических каналов удалось достичь за счет мультиплексирования с делением по длине волны. За счет этой техники удалось в 16-32 раза увеличить широколосность канала из расчета на одно волокно. Схема мультиплесирования показана на рис. 3.2.8. На входе канала сигналы с помощью призмы объединяются в одно общее волокно. На выходе с помощью аналогичной призмы эти сигналы разделяются. Число волокон на входе и выходе может достигать 32.
Рис. 3.2.8. Мультиплексирование с делением по длине волны в оптическом волокне
Открытый торговый протокол Интернет–
4.6. 1 Открытый торговый протокол Интернет– IOTP версия 1.0
Семенов Ю.А. (ГНЦ ИТЭФ)
Перевод Семенова Ю.А. (ГНЦ ИТЭФ)
Про то торговцы титулами знают,
Но, кроме денег, им на все плевать.
Джузеппе Джусти, "Шутки"
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 и т.д..
Каждая схема содержит некоторый обмен сообщениями, который является характерным именно для нее. Эти схемно-зависимые части протокола помещены в приложения к данному документу.
Документ не предписывает участникам, какое следует использовать программное обеспечение или процесс. Он определяет только необходимые рамки в пределах которых реализуется торговая операция.
2. Введение
Открытый торговый протокол Интернет определяет некоторое число различных операций IOTP:
Покупка. Осуществляет предложение, оплату и опционно доставку.
Возврат. Производит возврат платежа для покупки, выполненной ранее.
Обмен ценностями. Включает в себя два платежа, наприммер в случае обмена валют.
Аутентификация. Производит проверку для организации или частного лица – являются ли они тем, за кого себя выдают.
Отзыв платежа. Осуществляет отзыв электронного платежа из финансового учрежденрия.
Депозит. Реализует депозит средств в финансовом учреждении.
Запрос. Выполняет запрос состояния операции IOTP, которая находится в процессе реализации, или уже выполнена.
Пинг. Простой запрос одного приложения IOTP с целью проверки, функционирует ли другое приложение IOTP.
Эти операции считаются базовыми, позднее могут быть определены другие операции IOTP. Каждая из перечисленных выше операций IOTP включает в себя:
Некоторое число организаций, выполняющих торговую функцию и
Набор торговых обменов. Каждый торговый обмен включает в себя обмен данными между торговыми ролями в форме набора торговых компонентов.
2.1. Торговые роли
Торговые роли идентифицируют различные обязанности, которые может выполнять организации в процессе торговли. В IOTP используется пять торговых ролей, которые проиллюстрированы на рис. .1.
Рис. .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. | Покупатель проверяет информацию от продавца и решает, стоит ли осуществлять покупку. |
Предложение использует следующие торговые компоненты, которые пересылается между покупателем и продавцом.
Компонет статус используется для сообщения партнеру что сформирован корректный отзыв-предложение.
Компоненты Организации содержит информацию, которая описывает организации, исполняющие определенные торговые роли в данной сделке.
| Покупатель предоставляет информацию о том, кто он и, если товар или услуги доставлены, место, куда они доставлены. | |
| Продавец дополняет эту информацию данными о себе, о Кассире, Агенте обслуживания Покупателя и, если товар или услуга должна быть доставлена, то и об агенте доставки. |
| o | Компонент Заказа (Order Component) содержит описания товаров или услуг, предмет сделки, если покупателя устроит соглашение. Эта информация посылается Продавцом покупателю. |
| o | Компонент оплаты (Payment Component), генерируемый продавцом, содержит детали того сколько надо платить, в какой валюте и кто должен платить кому, например покупатель может попросить вернуть деньги. Заметим, что число платежей в сделке может быть больше одного. |
| o | Компонент Доставки (Delivery Component), также генерируемый продавцом, используется, если товары или услуги требуют доставки. Он содержит информацию о том, как будет осуществляться доставка, например с помощью обычной или электронной почты. |
| o | Компонент данных о торговых ролях содержит информацию, которую продавец хочет довести до сведения другой торговой роли, такой как Кассир или Агент доставки. |
| o | Компонент подпись "отклика на предложение", если присутствует, подписывает все выше перечисленные компоненты с целью гарантии их целостности. |
/p> Точное содержание информации, выданной Продавцом Покупателю, варьируется в зависимости от типа операции IOTP. Например:
низкая стоимость сделки может не требовать подписи
сумма оплаты может варьироваться в зависимости от фирмы и используемого протокола оплаты
некоторые предложения могут не включать в себя доставку товара
обмен ценностями включает два платежа
продавец может не предлагать покупателю каких-либо услуг.
Информация, предоставляемая покупателем продавцу, предоставляется различными способами, например, она может быть получена.
Используя [HTML] страницы, как часть "практики" покупателей.
Используя стандарт OPS (Open Profiling Standard), который был недавно предложен,
В форме компонентов Организации, ассоциирующихся с аутентификацией Покупателя Продавцом.
Как компоненты Заказа в последней версии IOTP.
2.2.2. Платежный обмен
Целью платежного обмена (Payment Exchange) является оплата, производимая покупателем еассиру или наоборот, используя вид и протокол платежа, выбранные покупателем. Второй целью является опционное обеспечение покупателя платежной распиской (Payment Receipt), которая может использоваться для связи платежа с его причиной, как это описано в обмене предложения (Offer Exchange).
Обмены платежа могут реализовываться различными способами. Наиболее общий случай, где сделка зависит от типа и платежного протокола, показан на диаграмме рис. .3. Возможны и более простые платежные обмены.
M
M
Рис. .3. Платежный обмен
Платежный обмен использует следующие торговые компоненты, которыми обмениваются покупатель, продавец и кассир:
Компонент списка типов платежей содержит перечень допустимых видов платежа (например, MasterCard, Visa, Mondex, GeldKarte), платежные протоколы (например, SET Version 1.0, SCCD (Secure Channel Credit Debit – имя, используемое для платежей через кредитные карточки, где неавторизованный доступ блокируется с помощью механизма формирования безопасного транспортного канала, такого как SSL/TLS), а также сумма и вид валюты. Продавец посылает список типов платежей покупателю. Покупатель сравнивает типы платежей, протоколы, тип валюты и сумму со своими возможностями и делает выбор.
Компонент выбора типа платежа содержит выбор покупателя. Тип платежа, протокол, вид валюты, сумма и возможно протокольно зависимая информация посылается продавцу. Эта информация используется для модификации данных предложения (Offer Exchange). Например, продавец может предложить скидку, с тем, чтобы стимулировать использование карточки накопления (store card).
Компонент Статус используется, чтобы проинформировать кассира, что обмен предложения успешно завершился, и кассиром для сообщения о благополучном завершении платежного обмена.
Компоненты Организаций генерируются Продавцом. Они содержат детали ролей Продавца и Кассира:
Компонент платеж содержит данные о сумме платежа, валюте и направлении оплаты (кто кому).
Компонент подпись "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. Обмен доставки
Целью обмена доставки является обеспечить физическую или сетевую доставку купленного товара или услуги покупателю. Второй целью служит передача покупателю “декларации о доставке”, предоставляя дополнительную информацию о доставке, такую как номера накладной или номер трайлера, с помощью которого будет доставлен груз. Результат доставки может быть также подтвержден с помощью электронной подписи. Обмен сообщениями показан на диаграмме ниже.
M
M
D
D
Рис. .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татус, и все соответствующие подписи, после чего предпринимает некоторые действия или останавливает процедуру. |
/p> Рис. .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 | Нужно | Нужно | Нужно | Нужно | Нужно | Нужно |
| Подпись | Нужно | Нужно | Нужно | Ограничено | Нужно | Нужно |
| Ошибка | Нужно | Нужно | Нужно | Нужно | Нужно | Нужно |
/p> В выше приведенной таблице:
"Нужно" означает, что торговая роль должна поддерживать операцию или торговый блок.
"Можно" означает, что программная реализация может поддерживать операцию или торговый блок по усмотрению разработчика.
"Зависит" означает, что программная реализация операции или торгового блока зависит от одного из следующих условий:
| - Поддерживаются базовые операции аутентификации IOTP; | |
| - Если требуется для данного метода платежа, как это определено в его сопровождающем документе IOTP. |
Решения IOTP должны поддерживать все операции IOTP и торговые блоки, необходимые, по крайней мере, для одной из ролей (колонка), как это описано в приведенной выше таблице для решений, которые считаются поддерживающими IOTP.
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 и его отношения с торговыми блоками и компонентами проиллюстрировано на диаграмме ниже.
Рис. .6. Структура сообщения IOTP
На диаграмме определена концепция блока ссылок операции (Transaction Reference Block). Такой блок содержит среди прочего уникальный идентификатор операции IOTP. Кроме того, каждому блоку и компоненту присваивается ID-атрибут (смотри раздел 3.4), который является уникальным в пределах IOTP. Следовательно, комбинации ID-атрибута и глобального уникального идентификатора в блоке ссылок операции достаточно, для однозначной идентификации любого торгового блока или компонента.
3.1.2. Операции IOTP
Предопределенный набор сообщений IOTP, которыми обмениваются торговые роли, составляют операцию IOTP. Это проиллюстрировано ниже на диаграмме.
Рис. .7. Функциональная схема операция IOTP
На приведенной выше диаграмме Интернет рассматривается в качестве транспортного механизма. Но это не всегда так. Сообщения IOTP могут транспортироваться с использованием различных механизмов.
В этой версии IOTP специфицированы следующие операции IOTP (смотри раздел 9):
Покупка. Поддерживает предложение, платеж и, опционно, доставку.
Возврат. Поддерживает возврат денег для сделанной ранее покупки.
Обмен ценностями. Включает в себя два платежа, которые реализуют обмен ценностями, например валютный обмен.
Аутентификация. Поддерживает удаленную аутентификацию одной торговой роли другой ролью с помощью различных аутентификационных алгоритмов, и предоставляет информацию об организации – торгового агента, который должен быть аутентифицирован с целью, например, подготовки предложения.
Отзыв. Поддерживает отзыв электронного платежа из финансовой организации.
Депозит. Поддерживает депозит электронного платежа в финансовой организации.
Запрос. Поддерживает запрос состояния транзакции IOTP, которая в данный момент реализуется или уже завершилась.
Ping. Эта операция поддерживает простой запрос, который позволяет одному приложению IOTP выяснить, работает ли некоторое другое приложение IOTP.
3.2. Сообщение IOTP
Как было описано выше, сообщения IOTP представляют собой [XML] документы, которыми обмениваются торговые роли, участвующие в сделке.
XML-определение сообщения IOTP выглядит следующим образом.
<!ELEMENT IotpMessage
( TransRefBlk,
) >
<!ATTLIST IotpMessage
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. Например:
<?XML Version='1.0'?>
<!DOCTYPE IotpMessage >
<IotpMessage>
...
3.3. Блок ссылок операции (Transaction Reference Block)
Блок ссылок транзакции содержит информацию, которая идентифицирует IOTP-транзакцию и сообщение IOTP. Блок ссылок операции включает в себя:
Компонент ID-операции, который однозначно идентифицирует операцию IOTP. Компоненты ID-операции идентичны для всех сообщений IOTP, относящихся к одной IOTP-операции.
Компонент ID-сообщения, который предоставляет управляющую информацию о сообщении IOTP, а также однозначно идентифицирует сообщение IOTP в рамках операции IOTP.
Нуль или более компонентов Related To, которые связывают эту операцию IOTP с другими операциями или другими событиями, используя идентификаторы этих событий.
Определение блока ссылок операции (Transaction Reference Block) выглядит следующим образом:
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок ссылок операции в пределах IOTP-процедуры (смотри раздел 3.4). |
| TransId | Смотри 3.3.1 Id-компонент операции. |
| MsgId | Смотри 3.3.2 Id-компонент сообщения. |
| RelatedTo | Смотри 3.3.3 Компонент Related To. |
3.3.1. Идентификационная компонента транзакции
Идентификационная компонента транзакции содержит информацию, которая однозначно задает транзакцию IOTP. Ее определение представлено ниже:
<!ELEMENT TransId EMPTY >
Атрибуты:
| 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 |
/p> Значение IotpTransType управляется процедурой, описанной в разделе 12 IANA Considerations, которая позволяет пользователю определить величины IotpTransType. В последних версиях IOTP, этот список будет расширен с целью поддержки различных типов транзакций IOTP. Вероятно, будет поддержан динамический тип (Dynamic), который указывает, что последовательность шагов в транзакции не является стандартной.
| TransTimeStamp | Там где система, запускающая транзакцию IOTP, имеет внутренние часы, атрибут устанавливается равным времени старта транзакции IOTP в формате [UTC]. |
Некоторые системы не могут генерировать временные метки. В этом случае этот атрибут должен содержать значение "NA" (Not Available).
3.3.2. Идентификатор сообщения
Компонент Id-сообщения предоставляет контрольную информацию о сообщении IOTP, а также однозначно идентифицирует сообщение в рамках транзакции IOTP. Его определение выглядит следующим образом.
<!ELEMENT MsgId EMPTY >
Атрибуты:
| 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]. |
/p>
3.3.3. Компонент Related To
Компонент Related To связывает транзакции IOTP с другими транзакциями или другими событиями с помощью идентификаторов этих событий. Определение этого компонента представлено ниже.
<!ELEMENT RelatedTo (PackagedContent) >
RelnKeyWords NMTOKENS #IMPLIED >
Атрибуты:
| ID | Идентификатор, который однозначно jghtltkztn компонент Related To в рамках транзакции IOTP. |
| xml:lang | Определяет язык, использованный атрибутом или дочерним элементом в данном компоненте, если не переписан атрибутом xml:lang дочернего элемента. Смотри раздел 3.8. |
| RelationshipType | Определяет тип отношения. Корректными значениями являются: |
Ссылка, в случае которой элемент Packaged Content содержит указатель на некоторый другой, не-IOTP документ.
Значения RelationshipType управляются процедурами, определенными в разделе 12 IANA Considerations, которые позволяют пользователю определить свои значения атрибута.
Целью атрибута является обеспечение торговых ролей, включенных в транзакцию IOTP, объяснением природы отношений между транзакциями. Следует позаботиться о том, чтобы слова, использованные в атрибуте Relation, правильно указывали "направление" отношений. Например: одна транзакция может быть возвратом денег для другой выполненной ранее транзакции. В этом случае транзакция, которая возвращает деньги, должна содержать слова атрибута Relation, такие как "возврат за", а не "возврат кому" или просто "возврат".
| RelnKeyWords | Этот атрибут содержит ключевые слова, которые могут быть использованы, чтобы помочь идентифицировать подобные отношения, например все виды возвратов. Ожидается, что рекомендуемые ключевые слова будут выбраны в процессе практического использования. В этой версии спецификации не содержится никаких специальных рекомендаций по ключевым словам |
/p> 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)*
Для сообщений, которые содержат торговый блок информационного запроса или блок запроса Ping, префикс делается равным "I" (Inquiry).
Для сообщений, которые содержат торговый блок отклика на информационный запрос или блок отклика Ping, префикс равен "Q".
Префикс для других торговых ролей в сделке содержится в компоненте Organisation (организации) и прописывается обычно Продавцом. Ниже представлены рекомендуемые значения:
| о | "P" - Первый Кассир |
| o | "R" – Второй Кассир |
| o | "D" – Агент доставки |
| o | "C" – Доставка (Deliver To) |
/p> Префиксы должны содержать один символ. NameChar имеет то же значение, что и определение NameChar в [XML].
Короче Id-компонент первого сообщения IOTP, посланного Покупателем будет иметь ID-атрибут "C1", второе - "C2", третье - "C3" и т.д. Цифра имеет то же определение что и в [XML].
3.4.2. Определения ID-атрибута для блока и компонента
ID-атрибут блоков и компонентов в пределах транзакции IOTP также должен быть уникальным. Ниже представлено его определение:
BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix
IdSuffix ::= Digit (Digit)*
В IOTP, торговые компоненты и торговые блоки копируются из одного сообщения IOTP в другое. I D-атрибут не изменяется, когда существующий торговый блок или компонент копируется в другое сообщение IOTP.
| IdSuffix | Суффикс состоит из одной или более цифр. Суффикс должен быть уникальным для ID-атрибута ID-компонента сообщения, используемого для генерации ID-атрибута. Рекомендуется здесь следующее: |
| o | Первому блоку или компоненту, посылаемому торговой ролью присваивается суффикс "1" |
| o | Для второго и далее блоков или компонентов ID-атрибуты увеличивается на 1 для каждого последующего сообщения. |
| o | Суффикс не может содержать начальных нулей. |
3.4.3. Пример использования ID-атрибутов
На диаграмме проиллюстрировано, как используются значения ID-атрибутов.
Рис. .8. Пример использования ID-атрибутов
3.5. Элемент References
Торговый компонент или один из его дочерних XML элементов может содержать XML-атрибут, который указывает на другой блок (т.e. Блок ссылок транзакции или торговый блок) или торговый компонент (включая идентификатор транзакции и компонент подписи). Эти ссылки элементов используются для многих целей, ниже предлагается несколько примеров:
Идентификация элементов XML, чей дайджест включен в компонент подписи.
Указание на компонент организации кассира, который используется при платеже.
Элементы Reference всегда содержат значение ID-атрибута блокаили компонента. Идентификация сообщения IOTP, торговогоблока или торгового компонента, на который указывает ссылка элемента, включает в себя наождение XML-элемента, который:
Принадлежит той же самой IOTP-транзакции (т.e. Id-компонет транзакции и IOTP-сообщения совпадают).
Имеет значение ID-атрибута элемента соответствующее значению ссылки элемента.
Термин "соответствует" в данной спецификации имеет то же определение, что и в [XML]. Пример "соответствия" ссылки элемента показан ниже.
Рис. .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:Critical" со значением "True" и IOTP уведомлен приложением, что оно не знает как обрабатывать элемент и его дочерние элементы, тогда транзакция IOTP выдает техническую ошибку (смотри раздел 4.1).
Если дополнительный XML-элемент имеет атрибут "IOTP:Critical" со значением "False", тогда транзакция IOTP может продолжать работу, если 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).
В общем, он используется для инкапсуляции одного или более потоков данных. Этот поток данных имеет три стандартизованных атрибута, которые служат для идентификации, декодирования и интерпретации содержимого. Его определение представлено ниже.
<!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent Name CDATA #IMPLIED Content NMTOKEN "PCDATA" Transform (NONE|BASE64) "NONE" >
Атрибуты:
Name |
Опционно. Позволяет разделить случаи множественного применения элементов PackagedContent в одной и той же точке IOTP. Например: |
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
<PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45
</PackagedContent>
</ABCD>
Атрибут имени может быть опущен, например, если имеется только один элемент PackagedContent.
Content |
Идентифицирует, какой тип данных находится в содержимом элемента PackagedContent. Корректными значениями атрибута Content являются: |
| о | PCDATA . Содержимое элемента PackagedContent может рассматриваться как PCDATA и более не обрабатываться. |
| о | MIME . Содержимое элемента PackagedContent является MIME-объектом. Обработка должна включать поиск MIME-заголовков внутри элемента PackagedContent. |
| о | MIME:mimetype . Содержимое элемента PackagedContent является MIME-объектом с заголовком "Content-Type: mimetype". Хотя допускается иметь MIME:mimetype с атрибутом Transform равным NONE, более желательно иметь атрибут Transform равным BASE64. Заметим, что, если используется Transform = NONE, тогда все содержимое должно соответствовать PCDATA. Некоторые символы будет нужно закодировать как объекты XML, или как символьные объекты. |
| о | XML . Содержимое элемента PackagedContent может рассматриваться как XML-документ. Следует использвать секции CDATA, или Transform = BASE64, чтобы гарантировать, что содержимое элемента PackagedContent соответствует PCDATA. |
Transform |
Идентифицирует преобразование, которое было произведено нс даннвми, прежде чем они были помещены элемент. Допустимыми значениями являются: |
/p> 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.
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). |
/p>
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" потерянного атрибута. |
4.5.2.2. Выявление и обработка дублированных сообщений
Если входное сообщение может быть идентифицировано, как корректное, то проверяется, не получалось ли раньше точно такое же сообщение. Под идентичностью здесь подразумевается, что все блоки, компонентя, элементы, значения атрибутов и элементы содержимого тождественны.
Рекомендуемым способом проверки идентичности сообщений является проверка равентства их [DOM-HASH].
Если получено сообщение, прежде чем его исследовать, нужно проверить, завершилась ли обработка предыдущего.
Если обработка не завершилась, генерируется компонент Error с атрибутом Severity = TransientError и кодом ошибки = MsgBeingProc, чтобы указать, что сообщение обрабатывается и послать его обратно отправителю, с предложением повторной присылки поздее.
4.5.2.3. Обработка недублированных сообщений
Если установлено, что сообщение не является дубликатом ранее полученного, тогда оно обрабатывается. Процедура обработки включает в себя:
| o | проверку того, что сервер готов для обработки, если это не так, генерируется переходная ошибка; |
| o | проверку, не находится ли транзакция в режиме ошибки или неаннулирована; |
| o | контроль корректности входного сообщения, который предусматривает: |
| - проверку глубины ошибки сообщения; | |
| - проверку ошибок блочного уровня; | |
| - проверку любых инкапсулированных данных | |
| o | проверку ошибок в последовательности полученных блоков; |
| o | генерацию компонентов ошибки для любых обнаруженных ошибок; |
| o | если никаких серьезных или переходных ошибок не выявлено, производится обработка сообщения и, если требуется, генерация отклика отправителю входного сообщения. |
Процесс обработки входного сообщения должен проверить, свободна ли остальная система. Если сервер слишком занят, он должен выдать компонент 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, которая распознана сервероим, то это серьезная ошибка. |
/p> Если сгенерированы какие- либо компоненты 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 | зависит оттого, нужен или нет ввод со стороны человека. |
| o | TimedOutRcvr, если транзакция может быть восстановлена позднее, или |
| o | TimedOutNoRcvr, если транзакция невосстановима. |
4.6. Последовательность обработки для роли клиента
"Роль клиента" в IOTP является торговой ролью Покупателя.
Компания или организация, которая является Продавцом может, например, взять на себя роль покупателя, делая покупки или или выполняя отзыв электронного платежа.
В частности Покупатель должен быть способен:
| o | Инициировать транзакции (смотри раздел 4.6.1). Среди них могут быть: |
| - платеж, связанный с транзакцией | |
| - инфраструктурные транзакции. | |
| o | Воспринять и обработать сообщение, полученное от другой торговой роли (смотри раздел 4.6.2). Сюда входит: |
| - идентификация того, принадлежит ли сообщение транзакции, запущенной ранее; | |
| - обработка дублированных сообщений; | |
| - генерирование переходных ошибок, если сервер, который обрабатывет входное сообщение перегружен; | |
| - обработка сообщения, если оно не имеет ошибок и, если необходимо, посылка отклика партнеру по результатам обработки. | |
| o | Аннулировать текущую транзакцию, если поступил соответствующий запрос, например от пользователя (смотри раздел 4.6.3). |
| o | Повторно передать сообщение, если ожидаемый отклик не пришел своевременно (смотри раздел 4.6.4). |
/p>
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) ошибка. |
/p>
4.6.3. Аннулирование операции
Этот процесс аннулирует текущую транзакцию системы покупателя в результате внешнего запроса пользователя или другой системы или сервера, исполняющего роль покупателя. Обработка запроса делается также как для сервера IOTP (смотри раздел 4.5.3).
4.6.4. Повторная передача сообщений
Ретрансмиссия сообщений осуществляется так же, как и в случае сервера IOTP (смотри раздел 4.5.4).
5. Соображения безопасности
Здесь рассматриваются следующие проблемы:
| o | определение того, следует ли использовать электронную подпись; |
| o | конфиденциальность данных; |
| o | безопасность платежного протокола. |
5.1. Принятие решения о применении электронной подписи
Использование электронной подписи в IOTP является исключительно опционным. IOTP может успешно работать вообще без цифровых подписей.
В конце концов, использовать ли цифровую подпись, решает продавец или другая торговая роль, покупатель же решает обеспечивает ли приемлемый уровень риска вариан без электронной подписи. Если продавцы выяснят, что транзакции без подписей не приемлемы, то они имеют следующий выбор:
o начать использовать подписи,
o найти метод работы, где не требуются подписи или,
o выбрать более низкий объем и стоимость торговых операций.
Перечень некоторых причин использования цифровых подписей представлен ниже:
Продавец (или другая торгвая роль) хочет продемонстрировать, что ему можно верить. Если, например, продавец генерирует подпись отклина-предложения (смотри раздел 7.19.2), используя сертификат, полученный от третей стороны, известной покупателю, тогда покупатель может проверить подпись и сертификат, после чего он сможет с приемлемой достоверностью доверять тому, что предложение получено от означенной организации-продавца. В этом случае подписи используют асимметричную криптографию.
Продавец, или другая торгвая роль, хочет сгенерировать запись транзакции, которая подходит для определенной цели. Например, с приемлемой достоверностью цифровые подписи могут быть использованы Покупателем, чтобы определить:
Кассир или агент доставки, должен знать, что запрос не видоизменен и авторизован. Например, в IOTP, детали того, сколько нужно платить, посылаются покупателю в предложенпии-отклике и затем переадресуются кассиру в платежном запросе. Если запрос не подписан, покупатель может изменить сумму, например, удалив одну цифру. Если Кассир не имеет доступа к исходной платежной информации отклика-предложения, тогда в отсутствии подписи, кассир не может быть уверен, что данные не были модифицированы. Аналогичго, если платежная информация не подписана цифровым образом, кассир не может быть уверен, кто является продавцом, запросившим этот платеж.
Кассир или агент доставки хочет предоставить неопровержимую запись совершения платежной операции или выполнения доставки. Если платежный отклик или отклик доставки подписан, тогда покупатель может позднее использовать запись о платеже или доставке, чтобы доказать, что она состоялась. Это может использоваться, например, для целей обслуживания покупателя.
Ниже приводится список некоторых причин, почему электронная подпись может не использоваться:
Торговые роли иногда объединяются, следовательно изменения данных, выполненные покупателем могут быть обнаружены. Одной из причин использования подписи, это выявление того, что изменения внесены покупателем или другим партнером. Однако, если торговые роли имеют доступ к необходимым данным, то можно провести сравнение, нпример, информацию из платежного запроса и из отклика предложения. Доступ к данным может быть реализован, например, продавцом и кассиром, работающими в одной организации.
Стоимость криптографии слишком велика. Например, если платеж составляет всего несколько центов, стоимость выполнения криптографических операций, сопряженных с генерацией и проверкой цифровой подписи делает последнюю экономически не целесообразной.
5.2. Симметричная и асимметричная криптография
Преимущество использования симметричных ключей заключается в искдючении инфраструктуры, сопряженной с обслуживанием открытых ключей. В этом случае Продавец, Кассир и Агент доставки должны договориться об использовании общего секретного ключа.
Однако неудобства симметричной криптографии заключается в том, что покупатель не может надежно идентифицировать Продавца, Кассира и Агента доставки с которыми он имеет дело. Это существенно понижает доверие системе покупателя.
Однако следует заметить, что даже в случае использования асимметричной криптографии Покупатель не нуждается в цифровых сертификатах, так как целостность транзакции определяется кассиром, проверяющим подпись отклика предложения, скопированную с платежного запроса.
Заметим, что в одной транзакции может использоваться симметричная, асимметричная криптография или обе ее разновидности.
5.3. Конфиденциальность данных
Конфиденциальность информации обеспечивается путем пересылки IOTP-сообщений между торговыми ролями, используя секретный канал, такой как [SSL/TLS]. Использование безопасного канала в IOTP является опционным.
5.4. Безопасность платежного протокола
IOTP сконструирован так, чтобы быть нечувствительным к используемому платежному протоколу.
IOTP способствует безопасности, используя цифровые подписи для установления однозначного соответствия запроса и отклика и для аутентификации отправителя сообщений. Например 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-компонента транзакции (не покаазан); компонентов организаций (Продавца, Кассира, Агента доставки); компонент списка видов платежа; компонент заказа, платежный компонент, компонент доставки и компонент выбора вида платежа (если покупка зависит от вида платежа).
Рис. .11. Пример использование подписи при покупке
6.1.2. Элементы OriginatorInfo и RecipientInfo
Атрибут OriginatorRef элемента OriginatorInfo в компоненте подписи содержит ссылку на элемент (смотри раздел 3.5), которая указывает на комполнент организации, сгенерировавшей подпись. В данном примере это продавец.
Заметим, что значение элемента атрибута с атрибутом типа, устанавленным равным типу подписи IOTP, должно соответствовать торговой роли организации, которая его подписала. Если это не так, возникает ошибка. Корректные значения представлены ниже в таблице.
Атрибут RecipientRefs элемента RecipientInfo в компоненте подписи содержит ссылки элементов на компоненты организации, которая должна использовать подпись, чтобы проверить:
| о | они имеют отношение к организации, генерировавшей подпись, |
| о | данные, защищенные подписью, не были изменены, |
| о | данные были подписаны корректно |
| о | действия, которые нужно предпринять для продавца авторизованы. |
6.1.3. Использование подписей для подтверждения корректного завершения операций
Проверка успешного завершения операции осуществляется с помощью подписи данных сообщений-откликов. В частности:
для отклика предложения, когда продавец делает предложение Покупателю, котоорое может быть затем послано:
Для платежного отклика, когда Кассир генерирует платежную расписку, которая может быть послана:
Отклик доставки, когда Агент доставки генерирует накладную (Delivery Note). Это может быть использовано, чтобы проверить по завершении, что все сделано так как надо.
Отклик доставки. Один метод аутентификации партнера по сделке заключается в посылке запроса аутентификации, где определено, что эта процедура предсматривает использование электронной подписи.
Запрос состояния транзакции. Блок отклика информационного запроса может быть снабжен цифровой подписью, чтобы удостоверить аутентичность отклика.
Ping. Отклик Ping может быть подписан, чтобы иметь возможность проверки распознаваемости подписи.
6.2. Проверка корректности вычисления подписи
Проверка корректности вычисления электронной подписи является частью проверки ошибок уровня сообщения (смотри раздел 4.3.2).
Прежде чем торговая роль сможет проверить подпись, она должна идентифицировать, какой из элементов подписи следует проверить. При этом производятся следующие действия:
проверка того, что блок подписи присутствует и содержит один или более компонентов подписи;
идентификация компонента Organisation, который содержит OrgID-атрибут организации, осуществляющей проверку. Если не найдено ни одного компонента организации или обнаружено более одного такого компонента, фиксируется ошибка;
использование ID-атрибута компонента организации, чтобы найти элемент RecipientInfo, который содержит атрибут RecipientRefs, имеющий отношение к компоненту Organisation. Заметим, что может не быть подписи и по этой причине нечего проверять.
проверка компонента Signature, который содержит идентифицированный элемент RecipientInfo в виде:
вычислены правильно. При этом предполагается, что компоненты или блоки, на которые ссылается дайджест, были получены организацией, выполняющей проверку подписи.
6.3. Проверка платежа или доставки
Далее описываются процессы, необходимые для кассира или агента доставки, чтобы проверить возможность выполнения платежа или доставки. Это может включать проверку подписей, если она специфицирована продавцом.
При этом осуществляются следующие шаги:
проверка того, что платежный запрос или запрос доставки посланы правильной организацией;
проверка того, что в запросе представлены правильные компоненты IOTP;
проверка того, что платеж или доставка авторизованы.
В данном разделе используются следующие термины:
"Блок запроса" используется в связи с блоком запроса платежа (смотри раздел 8.7) или блоком запроса доставки (смотри раздел 8.10), если не специфицировано обратного;
"Блок отклика" используется в связи с блоком платежного отклика (смотри раздел 8.9) или блоком отклика доставки (смотри раздел 8.11);
"Операция" используется в связи с операцией, которая реализуется при получении блока запроса. Операцией может быть платеж или доставка;
"Операционная организация" используется в отношении Кассира или Агента доставки, которые реализуют операцию;
"Подписант операции" используется в отношении организации, которая подписаладанные об операции с целью ее авторизации;
"Верификатор операции" используется в отношении организаций, которые верифицируют данные, чтобы определить, авторизованы ли они для выполнения операции;
атрибут ActionOrgRef содержит ссылки элемента, которые могут быть использованы для идентификации "Операционной организации", которая должна выполнить операцию.
6.3.1. Проверка того, что блок запроса послан правильной организацией
Проверка того, послан ли блок запроса правильной организации, варьируется в зависимости от того платеж это или доставка.
6.3.1.1. Платеж
Кассир проверяет, может ли он принять или выполнить платеж путем идентификации компоненты платежа в полученном им блоке платежного запроса. Затем, используя ID плетежного компонента для идентификации организации, выбранной Покупателем, проверяет, что это та самая организация. Метод доступа к данным для решения поставленных задач проиллюстрирован на рис. .12.
Рис. .12. Проверка того, что Кассир может осуществить платеж
Далее выполняются следующие процедуры:
Идентификация платежного компонента (смотри раздел 7.9) в блоке полученного платежного запроса.
Идентификация компонентов списка видов платежа и выбора вида платежа для платежного компонента. Это включает в себя:
идентификация элементов вида платежа, платежного протокола и суммы в пределах списка видов платежа, который был выбран Покупателем. Это включает:
атрибута соответствует величине атрибута ProtocolAmountRef в компоненте выбора вида платежа. Если не обнаружено ни одного или более одного протокольного элемента суммы, возникает состояние ошибки.
атрибута которого соответствует величине атрибута PayProtocolRef в идентифицированном протокольном элементе суммы. Если не обнаружено ни одного или более одного подходящего элемента платежного протокола суммы, возникает состояние ошибки.
атрибута которого соответствует величине атрибута CurrencyAmountRef в компоненте выбора вида платежа. Если не обнаружено ни одного или более одного подходящего элемента валютной суммы, возникает состояние ошибки.
Проверяется совместимость ссылок в списке видов платежа и компонентов выбора вида платежа:
Проверяется то, что кассир, который получил блок платежного запроса является кассиром, выбранным покупателем. Это включает в себя:
6.3.1.2. Доставка
Способ доступа к данным Агента доставки при проверке того, может ли он выполнить доставку показан на рис. .13.
Start
|
v
Y">Delivery
Component
|
|ActionOrgRef
|
v
Organisation
Component
|
-Trading Role
Element
(Delivery Handler)
Рис. .13. Проверка того, что агент доставки может выполнить доставку
Процедура включает в себя следующие шаги:
Идентификацию компонента Delivery в блоке запроса доставки. Если не обнаружено ни одного или более одного подходящего компонента доставки, возникает состояние ошибки.
Использование атрибута ActionOrgRef компонента доставки для идентификации компонента Organisation
агента доставки. Если не обнаружено ни одного или более одного подходящего компонента Organisation, возникает состояние ошибки.
Если компонент Organisation для Агента доставки не имеет элемента торговой роли с атрибутом Role агента доставки, то это ошибка.
Наконец, если организация, которая получила блок запроса доставки не идентифицирует компонент Organisation для агента доставки, то это ошибка.
6.3.2. Проверка компонентов Correct, присутствующих в блоке запроса
Далее проверяется то, что в блоке платежного запроса (смотри раздел 8.7) или запроса доставки (смотри раздел 8.10) присутствуют правильные компоненты. Если компоненты отсутствуют, то это ошибка.
6.3.3. Проверка авторизованности операции
Предыдущие шаги идентифицировали операционную организацию и проверяли наличие всех необходимых компонент. На данном этапе проверяется, что операционная организация авторизована для выполнения данной процедуры.
Операционная организация идентифицирует Продавца, проверяет, что с ним имеется соглашение, которое допускает выполнение операции, и что любые ограничения этого соглашения выполнены, тогда, если требуются подписи, проверяется, что они подтверждают корректные данные. Эти шаги включают в себя:
идентификацию Продавца. Это компонент Organisation с элементом торовой роли, который имеет атрибут Role со значением Продавец. Если не обнаружено ни одного или более одного подходящего элемента торговой роли, возникает состояние ошибки.
проверку наличия соглашений операционных организаций с Продавцом, позволяющих выполнение операции. Чтобы решить эту задачу операционная организация должна проверить, что:
Проверка корректности подписей. Если подписи необходимы, они должны быть проверены. Это подразумевает:
транзакции (смотри раздел 9) может идентифицироваться одна или две подписи;
6.3.3.1. Проверка корректности дайджестов подписи
Все компоненты Signature, содержащиеся в IOTP-сообщении должны включать элементы Digest, которые относятся к:
Id компоненту транзакции (смотри раздел 3.3.1) сообщения IOTP, которое содержит компонент подписи. Это связывает глобально уникальный IotpTransId с другими компонентами, которые определяют транзакцию IOTP;
блоку ссылок транзакции (смотри раздел 3.3) первого сообщения IOTP, которое содержит подпись. Это связывает IotpTransId с информацией о сообщении IOTP, содержащемся в Id-компоненте сообщения (смотри раздел 3.3.2).
Необходима проверка того, что каждый компонент подписи содержит элементы дайджеста, которые относятся к корректным данным.
Элементы Digest, которые должны присутствовать, зависят от торговой роли организации, генерирующей цифровую подпись:
если подписант является продавцом, тогда:
если подписантом, формирующим цифровую подпись, является кассир, тогда элементы дайджеста должны присутствовать для:
7. Торговые компоненты
Далее рассматриваются торговые компоненты, используемые в IOTP. Торговые компоненты являются дочерними XML-элементами, что показано на диаграмме рис. .14.
Рис. .14. Торговые компоненты
Перечень торговых компонентов представлен ниже в порядке их вероятности использования:
Компонент протокольных опций
Компонент запроса аутентификации
Компонент отклика аутентификации
Компонент запроса информации о торговой роли
Компонент заказа
Компонент организации
Компонент списка видов платежа
Компонент выбора вида платежа
Компонент платежа
Компонент схема платежа
Компонент платежная расписка
Компонент доставки
Компонент данных доставки
Компонент накладной
Компонент подписи
Компонент сертификата
Компонент ошибки
Заметим, что следующие компоненты в других секциях этой спецификации:
Id-компонент транзакции (смотри раздел 3.3.1)
Id-компонент сообщения (смотри раздел 3.3.2)
7.1. Компонент протокольных опций
Опции протокола представляют собой опции, которые работают с транзакциями IOTP в целом. Определение компонента протокольных опций представлено ниже.
<!ELEMENT ProtocolOptions EMPTY >
<!ATTLIST ProtocolOptions ID ID #REQUIRED
xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED
SenderNetLocn CDATA #IMPLIEDSecureSenderNetLocn CDATA #IMPLIED
SuccessNetLocn CDATA #REQUIRED >
Атрибуты:
Этот компонент используется для облегчения выбора транзакции из списка подобных, например из базы данных транзакций IOTP, которые были запомнены Покупателем, Продавцом и т.д..
Это сетевая позиция, куда получатель блока TPO должен послать блок выбора TPO, если это требуется. Содержимое атрибута зависит от транспортного механизма.
| SecureSenderNetLocn | Содержит безопасный сетевой узел отправителя блока TPO, в котором содержится компонент протокольных опций. |
| SuccessNetLocn | Содержит сетевую позицию, которая должна быть отображена после успешного завершения транзакции. |
7.2. Компонент запроса аутентификации
Этот торговый компонент содержит параметр данных, которые используются при аутентификации одной торговой роли у другой. Его определение представлено ниже.
<!ELEMENT AuthReq (Algorithm, PackagedContent*)>
<!ATTLIST AuthReq ID ID #REQUIRED
AuthenticationId CDATA #REQUIREDContentSoftwareId CDATA #IMPLIED>
Если требуется, алгоритм может использовать данные вызова, содержащиеся в элементах Packaged Content из компонента запроса аутентификации. Формат Packaged Content является зависимым от алгоритма.
Атрибуты:
Cодержимое:
Алгоритмы, которые могут использоваться, идентифицированы атрибутом Name элемента Algorithm.
7.3. Компонент отклика аутентификации
Компонент отклика аутентификации содержит результаты аутентификационного запроса. Используется алгоритм, содержащийся в компоненте запроса аутентификации (смотри раздел 7.2) и выборанный из блока запроса аутентификации (смотри раздел 8.4).
В зависимости от выбранного алгоритма, результаты его применения будут содержаться в компоненте подписи, которая подтверждает отклик аутентификации, или в элементах Packaged Content компонента отклика аутентификации. Его определение представлено ниже.
<!ELEMENT AuthResp (PackagedContent*) >
<!ATTLIST AuthResp ID ID #REQUIRED
AuthenticationId CDATA #REQUIREDSelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Атрибуты:
| ID | Идентификатор, который для данной транзакции однозначно определяет компонент отклика аутентификации. |
| AuthenticationId | Идентификатор аутентификации, специфицированный аутентификатором, который был включен компонент запроса (смотри раздел 7.2). Это позволяет аутентификатору идентифицировать метод аутентификации. |
| SelectedAlgorithmRef | Ссылка элемента, которая определяет элемент алгоритма, сипользуемого для формирования отклика аутентификации. |
| ContentSoftwareId | Смотри раздел 14. Словарь. |
/p> Cодержимое:
Например, для заданной схемы платежа он может содержать данные, зависящие от этой схемы.
7.4. Компонент запроса информации торговой роли
Этот торговый компонент содержит список торговых ролей (смотри раздел 2.1), информация для которых запрошена. Результатом запроса торговой роли является набор компонентов Organisation (смотри раздел 7.6), которые описывают каждую из запрошенных торговых ролей. Его определение приведено ниже.
<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq ID ID #REQUIRED
TradingRoleList NMTOKENS #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент информационного запроса для торговой роли в рамках транзакции IOTP. |
| TradingRoleList | Содержит список из одной или более торговых ролей (смотри атрибут TradingRole элемента Trading Role – раздел 7.6.2), для которых была запрошена информация. |
7.5. Компонент заказа
Компонент Order содержит информацию о заказе. Его определение представлено ниже.
<!ELEMENT Order (PackagedContent*) >
<!ATTLIST Order ID ID #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. Словарь. |
/p> 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.
Ниже представлено определение компонента.
<!ELEMENT Org (TradingRole+, ContactInfo?, PersonName?, PostalAddress?)>
<!ATTLIST Org ID ID #REQUIRED
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 | Сетевая позиция, которая может быть использована для загрузки логотипа организации. |
Cодержимое:
| TradingRole | Смотри 7.6.2. Элемент торговой роли. |
| ContactInfo | Смотри 7.6.3. Элемент контактной информации. |
| PersonName | Смотри 7.6.4. Персональное имя. |
| PostalAddress | Смотри 7.6.5. Почтовый адрес. |
/p>
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 уникальным. |
newjerseybooks.comid организации-продавца;
westernbank.co.ukid организации-кассира;
consumer:1000247ABH/newjerseybooks.comid организации-покупателя выданный продавцом.
7.6.2. Элемент торговая роль
Этот элемент идентифицирует торговую роль человека или организации в данной транзакции IOTP. Заметим, что организация может иметь более чем одну торговую роль и несколько ролей может присутствовать в одном элементе Organisation. Определение элемента представлено ниже:
<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole ID ID #REQUIRED
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 равным: |
/p> HardError,
Предупреждение, но Покупатель решает не продолжать транзакцию.
TransientError и транзакция прерывается по таймауту.
Этот атрибут:
не должен присутствовать, когда TradingRole равно Покупатель или DelivTo,
должен присутствовать, когда TradingRole равно Продавец, Кассир или Агент доставки.
Содержимое атрибута зависит от транспортного механизма.
| ErrorLogNetLocn | Опционно. Содержит сетевую позицию, куда Покупателю следует посылать IOTP сообщения, которые содержат блоки Error с компонентами Error сатрибутом Severity равным: |
Предупреждение, но Покупатель решает не продолжать транзакцию,
TransientError и транзакция прерывается по таймауту.
Этот атрибут:
не должен присутствовать, когда TradingRole = Покупатель,
должен присутствовать, когда TradingRole равно Продавец, Кассир или Агент доставки.
Содержимое этого атрибута зависит от транспортного механизма.
Атрибут ErrorLogNetLocn может использоваться для посылки сообщений об ошибках программной компании или другой оргаанизации, ответственной за решение проблем с программами, которые посылают входные сообщения. Смотри раздел 7.21.1.
7.6.3. Элемент контактной информации
Этот элемент содержит информацию, которая может быть использована для контакта с организацией или частным лицом. Все атрибуты являются опционными, однако по крайней мере один из элементов контактной информации должен присутствовать. Его определения представлено ниже.
<!ELEMENT ContactInfo EMPTY >
| <!ATTLIST ContactInfo xml:lang | NMTOKEN #IMPLIED |
| Tel CDATA #IMPLIED | Fax CDATA #IMPLIED |
| Email CDATA #IMPLIED | NetLocn CDATA #IMPLIED > |
| xml:lang | Определяет язык данного элемента. Смотри раздел 3.8. |
| Tel | Телефонный номер, по которому можно контактировать с организацией. Заметим, что это текстовое поле и проверок корректности содержимого не производится. |
| Fax | Номер факса, по которому можно контактировать с организацией. Заметим, что это текстовое поле и проверок корректности содержимого не производится. |
| Адрес электронной почты, по которому можно контактировать с организацией. Заметим, что поле должно следовать регламентациям для адресных спецификаций, содержащимся в [RFC822]. | |
| NetLocn | Адрес Интернет, по которому можно найти информацию об организации, используя WEB-броузер. |
/p> Содержимое этого атрибута должно согласовываться с документом [RFC1738].
7.6.4. Элемент личного имени
Этот элемент содержит имя частного лица. Все поля являются опционными, однако GivenName (имя) или FamilyName (фамилия) должны присутствоать. Его опредление представлено ниже.
<!ELEMENT PersonName EMPTY >
| <!ATTLIST PersonName xml:lang | NMTOKEN #IMPLIED |
| Title CDATA #IMPLIED | GivenName CDATA #IMPLIED |
| Initials CDATA #IMPLIED | FamilyName CDATA #IMPLIED > |
| xml:lang | Определяет язык с помощью атрибута внутри элемента. Смотри раздел 3.8. |
| Title | Отличительное имя; личное прозвище, наследственное или нет, должность (напр., судья, мэр), дворянское звание (напр., герцог, герцогиня, граф), или используемое при обращение к человеку (напр., Mr, Mrs, Miss, товарищ, господин) |
| GivenName | Имя, под которым человек известен в семье, друзьям или знакомым (имя или фамилия). |
| Initials | Первая буква второго имени (отчества), под которым человек известен в своей семье, друзьям или знакомым. |
| FamilyName | Фамилия. Это обычно часть персонального имени, которая передается по наследству от родителей к детям. |
7.6.5. Элемен почтового адреса
Этот элемент содержит адрес, который может быть использован, например, для физической доставки товаров, услуг или писем. Его определение предлагается ниже.
<!ELEMENT PostalAddress EMPTY >
| <!ATTLIST PostalAddress xml:lang | NMTOKEN #IMPLIED |
| AddressLine1 CDATA #IMPLIED | AddressLine2 CDATA #IMPLIED |
| CityOrTown CDATA #IMPLIED | StateOrRegion CDATA #IMPLIED |
| PostalCode CDATA #IMPLIED | Country CDATA #IMPLIED |
Атрибуты:
| xml:lang | Определяет язык, используемый атрибутами в этом элементе. Смотри раздел 3.8. |
| AddressLine1 | Первая строка почтового адреса, напр.,"The Meadows" |
| AddressLine2 | Вторая строка почтового адреса. напр.,"Sandy Lane" |
| CityOrTown | Город в адресе, напр.,"Москва" |
| StateOrRegion | Штат или область в пределах страны, где находится город, напр., "Зюзино" |
| PostalCode | Код, известный как, например почтовый код или zip-код, который обычно используется почтовыми организациями для организации эффективной доставки, напр.,"113303" |
| Country | Страна адреса, напр.,"RU" |
| LegalLocation | Идентифицирует, является ли адрес зарегистрированным адресом организации. По крайней мере один адрес организации должен соответствовать значению “истина” в противном случае торговой ролью является Покупатель или DeliverTo. |
/p>
7.7. Компонент списка видов платежей
Компоненты списка видов платежа содержатся в блоке опций торгового протокола (смотри раздел 8.1) транзакции IOTP. Они содержат список:
виды платежа (смотри также раздел 11.1),
суммы, которые должны быть заплачены в валюте, которую выбрал или предложил Продавец,
платежные протоколы, которые могут использоваться для реализации заданного вида платежа,
сетевые позиции Кассиров, которые воспринимают платеж в рамках платежного протокола.
Определение компонента списка видов платежа представлено ниже.
<!ELEMENT BrandList (Brand+, ProtocolAmount+, CurrencyAmount+, PayProtocol+)>
<!ATTLIST BrandList ID ID #REQUIRED
xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED
PayDirection (Debit | Credit) #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент списка видов платежа транзакции IOTP. |
| xml:lang | Определяет язык, использованный атрибутами или дочерними элементами в пределах данного компонента, если только его значение не переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8. |
| ShortDesc | Текстовое описание на языке, заданном атрибутом xml:Lang, характеризующее цели списка видов платежа. Эта информация должна быть отображена у получателя списка видов платежа для того чтобы помочь сделать правильный выбор. Это привлекательно, так как позволяет Покупателю выяснить цели предлагаемого списка видов платежа, если транзакция предполагает несколько платежей. |
| PayDirection | Индицирует направление платежа для выбранного вида. Возможные значения: |
Кредит. Отправитель блока платежного запроса к которому имеет отношение список видов платежа, получит платеж от кассира.
Cодержимое:
| Brand | Описывает вид платежа (Brand). Последовательность элементов Brand (смотри раздел 7.7.1) в списке видов плптежа не определяет каких-либо преоритетов. Рекомендуется, чтобы программа, которая обрабатывает этот список видов платежа представляла их в порядке предпочтения получателя. |
| ProtocolAmount | Это связывает конкретный вид платежа с: |
/p> видами валюты и суммами в элементах CurrencyAmount, которые могут использоватьсясовместно с видами платежа, и
Платежными протоколами и Кассирами, которые могут использоваться с этими видами валюты и суммами для конкретного вида платежа.
| CurrencyAmount | Содержит код валюты и сумму платежа; |
| PayProtocol | Содержит информацию о платежном протоколе и Кассире, которые могут использовать данный вид платежа. |
Рис. .15. Отношения элементов списка видов платежа
Примеры списков видов платежа содержатся в главе 11.2.
7.7.1. Элемент Brand
Элемент Brand описывает вид платежа, который может быть использован при оплате покупки. Один или более таких элементов образуют компонент списка видов платежа, который имеет атрибут PayDirection, установленный равным Debit. Только один элемент вида платежа может содержаться в компоненте списка видов платежа (Brand List), который имеет атрибут PayDirection = Credit.
<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >
ContentSoftwareId CDATA #IMPLIED>
Атрибуты:
| ID | Идентификатор элемента, относящийся потенциально к компоненту выбора вида платежа (Brand Selection), содержащегося в последнем сообщении платежного запроса, и однозначно идентифицирующий элемент Brand данной транзакции. |
| xml:lang | Определяет язык, используемый атрибутами и содержимым данного элемента. Смотри раздел 3.8. |
| BrandId | Содержит уникальный идентификатор для вида платежа. Он используется для установления соответствия со списком платежных инструментов, которыми располагает Покупатель, чтобы определить, может ли он обеспечить платеж данного вида. |
| BrandName | Содержит название вида платежа, например MasterCard. Это описание вида платежа, которое отображается для Покупателя на понятном для него языке, заданном атрибутом xml:lang. Например, это может быть "American Airlines Advantage Visa". Заметим, что этот атрибут не используется для установления соответствия с инструментами платежа, которыми располагает Покупатель. |
| BrandLogoNetLocn | Сетевая позиция, которая может быть использована для загрузки логотипа организации. Смотри раздел “Получение логотипа” (раздел 10). |
/p> Содержимое этого атрибута должно соответствовать документу [RFC1738].
| BrandNarrative | Этот опционный атрибут предназначен для использования Продавцом для индикации специальных условий или выгод, которрые будут действовать, если Покупатель выбкерет определенный вид платежа. Например "5% скидка", "бесплатная доставка", "бесплатная гарантия на один год", и т.д.. |
| ProtocolAmountRefs | Идентифицирует протоколы и связанные с ними виды валюты и суммы, которые могут использоваться при данном виде платежа. Специфицируется как список ID протокольных колличественных элементов (смотри раздел 7.7.3), содержащихся в списке видов платежа. |
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| ProtocolBrand | Протокольные элементы вида платежа, которые содержат информацию о виде платежа, используемого с определенным платежным протоколом (смотри раздел 7.7.2) |
| PackagedContent | Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о виде платежа, который может использоваться платежным протоколом. Содержимое этой информации определяется в приложении для платежных протоколов, где описывается, как работает платежный протокол с IOTP. |
7.7.2. Элемент протокола вида платежа
Элемент протокола вида платежа содержит информацию, которая является специфической для применения определенного протокола к некоторому виду платежей. Его определение предложено ниже.
<!ELEMENT ProtocolBrand (PackagedContent*) >
<!ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #REQUIRED >
Атрибуты:
| ProtocolId | Должен согласовываться со значением атрибута ProtocolId в элементе платежного протокола (смотри раздел 7.7.5). |
| ProtocolBrandId | Это идентификатор вида платежа, который должен использоваться с конкретным платежным протоколом. Например, SET и EMV имеют свои определенные, различные значения для Brand Id, для каждого из протоколов. |
/p> Корректные значения этого атрибута описаны в приложении для платежных протоколов, идентифицированных ProtocolId, которые определяют, как платежный протокол работает с IOTP.
Cодержимое:
| PackagedContent | Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протоколе и/или виде платежа, которые может использовать платежный протокол. Содержимое этой информации определяется в приложении для платежных протоколов. |
7.7.3. Элемент Protocol Amount
Элемент Protocol Amount связывает вид платежа с:
видом валюты и суммами в элементах Currency Amount (смотри раздел 7.7.4), которые могут использоваться с данным видом платежа, и
платежными протоколами и Кассирами, определенными в элементе платежного протокола (смотри раздел 7.7.5), котоый может быть использован для этого видв валюты и сумм платежа.
Его определение представлено ниже:
<!ELEMENT ProtocolAmount (PackagedContent*) >
<!ATTLIST ProtocolAmount ID ID #REQUIRED
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. Словарь. |
| PackagedContent | Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протокольной сумме, которая может использоваться платежным протоколом. Содержимое этой информации определено в приложении для платежных протоколов. |
/p> Примеры элементов Protocol Amount приведены в секции 11.2.
7.7.4. Элемент валютной суммы
Элемент валютной суммы содержит в себе:
код валюты (и ее тип),
сумму.
Один или более таких элементов заключены в каждом компоненте списка видов платежа. Его определение приведено ниже:
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount ID ID #REQUIRED
>Amount CDATA #REQUIREDCurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED >
Атрибуты:
| ID | Идентификатор элемента, (Brand Selection), содержащиеся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент Currency Amount данной транзакции IOTP. |
| Amount | Указывает сумму, которая должна быть заплачена. Например $245.35 будет выражено как "245.35". Заметим, что значения меньше наименьшей целой величины вполне допустима. Например одна десятая цента будет записана как "0.001". |
| CurrCodeType | Указывает CurrCode области. Этот атрибут включен с тем, чтобы была возможность поддержания нестандартных "валют" например “торговых марок” и т.д.. Атрибут может принимать значения: |
IOTP указывает, что значения CurrCode управляются процедурой, описанной в разделе 12.
| CurrCode | Код, идентифицирующий валюту, которая должна использоваться при платеже. Область корректных кодов валюты определена атрибутом CurrCodeType. |
7.7.5. Элемент платежного протокола
Элемент платежного протокола специфицирует детали для платежного протокола и для Кассира, которые могут использоваться для жанного видв платежа. Один или более таких элементов содержится в каждом списке видов платежа.
<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
Атрибуты:
Значения ProtocolId определены схемой/методом платежа владельцев в документе, который описывает, как инкапсулировать платежный протокол в IOTP.
| ProtocolName | Описание платежного протокола и его версии на языке, идентифицированном атрибутом xml:lang. Например "Secure Electronic Transaction Version 1.0". Его целью является помочь, если требуется, в предоставлении информации об используемом платежном протоколе. |
| ActionOrgRef | Ссылка элемента (смотри раздел 3.5) на компонент Organisation для Кассира при данном платежном протоколе. |
| PayReqNetLocn | Сетевая позиция, указывающая куда следует послать платежный запрос в отсутствии гарантии безопасности при заданном протоколе. |
| SecPayReqNetLocn | Сетевая позиция, указывающая куда следует послать платежный запрос в условиях гарантии безопасности при заданном протоколе. Безопасный платеж предполагает для коммуникации с кассиром использование безопасного канала, такого как [SSL/TLS]. |
ContentSoftwareIdСмотри раздел 14. Словарь.
Cодержимое:
| PackagedContent | Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протоколе, который используется платежным протоколом. Содержание этой информации определяется в приложении для платежных ппротоколов. |
/p> Примеры элементов платежного протокола содержатся в разделе 11.2.
7.8. Компонент выбора вида платежа
Компонент выбора вида платежа идентифицирует выбор вида платежа, платежный протокол и кассира. Этот элемент используется:
в сообщениях платежных запросов в транзакциях покупки и обмена ценностями для идентификации вида платежа, протокола и кассира;
чтобы опционно проинформировать продавца об используемом виде платежа с целью возможной последующей коррекции предложения и заказа.
В базовой версии IOTP, целостность компонентов выбора вида платежа не гарантируется. Однако модификация компонентов выбора вида платежа может привести лишь к отказу обслуживания, если сам платежный протокол безопасен и контролирует модификацию или дублирование сообщений и может противостоять любым другим атакам.
Определение компонента выбора вида платежа представлено ниже.
<!ELEMENT BrandSelection (BrandSelBrandInfo?, BrandSelProtocolAmountInfo?,
BrandSelCurrencyAmountInfo?) >
<!ATTLIST BrandSelection ID ID #REQUIRED
| BrandListRef NMTOKEN #REQUIRED | BrandRef NMTOKEN #REQUIRED |
CurrencyAmountRef NMTOKEN #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент выбора вида платежа транзакции. |
| BrandListRef | Ссылка элемента (смотри раздел 3.5) компонента списка видов платежа, из которого был выбран Brand. |
| BrandRef | Ссылка элемента Brand компонента списка видов платежа, который был выбран из списка и использован для платежа. |
| ProtocolAmountRef | Ссылка элемента для Protocol Amount в пределах компонента списка видов платежа, который использован при платеже. |
| CurrencyAmountRef | Ссылка элемента для Currency Amount в пределах компонента списка видов платежа, который использован при платеже. |
|
BrandSelBrandInfo, BrandSelProtocolAmountInfo, Содержит любые дополнительные данные, которые могут быть необходимы при конкретном платеже или протоколе. Смотри разделы 7.8.1, 7.8.2, и 7.8.3. |
/p> Используются следующие правила:
атрибут 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 для платежных методов, где описано применние этого элемента.
<!ELEMENT BrandSelBrandInfo (PackagedContent+) >
<!ATTLIST BrandSelBrandInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED >
Атрибуты:
| ContentSoftwareId | Смотри раздел 14. Словарь. |
7.8.2. Элемент Amount Info протокола выбора вида платежа
Элемент Amount Info протокола выбора вида платежа содержит любую дополнительную информацию, зависящую от платежного протокола, которая может быть необходима для конкретного вида платежа или плптежного протокола. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+)>
<!ATTLIST BrandSelProtocolAmountInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
Атрибуты:
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Элементы Packaged Content (смотри раздел 3.7), которые могут содержать дополнительную информацию, необходимую для конкретного вида платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента. |
7.8.3. Информационный элемент валютной суммы выбора вида платежа (Brand Selection Currency Amount Info)
Информационный элемент валютной суммы выбора вида платежа содержит любую дополнительную информацию, зависящую от вида платежа и валюты, которая может быть необходима при конкретном виде платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+)>
<!ATTLIST BrandSelCurrencyAmountInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
Атрибуты:
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Элементы Packaged Content (смотри раздел 3.7), которые содержат дополнительную информацию, относящуюся к виду платежа и валюты. Смотри приложение IOTP по платежным методам, где описано использование этого элемента. |
7.9. Компонент платежа (Payment)
Компонент платежа содержит информацию, используемую для управления процедурой выполнения платежа. Он предоставляет информацию о:
Временном интервале в пределах которого Кассир может начать платежную операцию;
Ссылку на список видов платежа (смотри раздел 7.7), который идентифицирует виды платежа, протоколы, виды валюты и суммы, которые могут использоваться при осуществлении платежа.
следует ли предоставлять платежную расписку;
должен ли данному платежу предшествовать другой платеж.
Его определение выглядит следующим образом.
<!ELEMENT Payment EMPTY >
<!ATTLIST Payment ID ID #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]-сообщение. Определение компонента представлено ниже.
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData ID ID #REQUIRED
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент схемы оплаты транзакции IOTP. |
| PaymentRef | Ссылка элемента (смотри раздел 3.5) компонента платежа (смотри раздел 7.9), с которым связан компонент схемы платежа. Атрибут необходим, если только компонент схемы платежа не является частью запроса состояния транзакции (смотри раздел 9.2.1). |
| ConsumerPaymentId | Идентификатор, специфицированный Покупателем, который в случае возвращения Кассиром в другом компоненте схемы платежа (или другим способом) позволит Покупателю определить, о каком платеже идет речь. |
| PaymentHandlerPayId | Идентификатор, специфицированный Кассиром, который в случае возвращения Покупателем в другом компоненте схемы платежа (или другим способом) позволит Кассиру определить, о каком платеже идет речь. Атрибут необходим для каждого компонента схемы платежа, вне зависимости от того, что содержится в блоке платежного запроса. |
| ContentSoftwareId | Смотри раздел 14. Словарь. |
/p> Cодержимое:
| PackagedContent | Содержит протокольную информацию о схеме платежа в виде элементов Packaged Content (смотри раздел 3.7). Определение содержимого смотри в приложение по схемам платежа. |
значения атрибута Name каждого элемента pakaged content определены в приложении для платежных протоколов;
значение каждого Name должно быть уникальным для платежа, где платеж определяется как совокупность всех платежных схем или компонентов платежных расписок с идентияным значением атрибута PaymentRef.
7.11. Компонент платежной расписки
Плптежная расписка представляет собой запись о платеже, которая показывает, какая сумма заплачена или получена. Она отдичается от расписки о покупке, тем что здесь нет записи о том, что куплено. Обычно в компоенте платежной расписки содержатся данные, которые описывают:
сумму платежа и его валюту;
дату и время платежа;
внутренние числовые ссылки, которые идентифицируют платеж для платежной системы;
цифровые подписи, выработанные платежным механизмом и призванные позднее подтвердить, что платеж состоялся.
Если использованный платежный метод сконфигироирован соответствующим образом, то компонент платежной расписки должен содержать сообщения платежного протокола или ссылки на сообщения, которые подтверждают выполнение платежа.
Точное определение содержимого платежной расписки зависит от метода платежа. Информация, содержащаяся в компоненте платежной расписки, должна отображаться или каким-либо другим способом доводиться до сведения Покупателя.
Если компонент платежной расписки содержит сообщения платежного протокола, тогда они должны быть обработаны программой метода платежа,чтобы преобразовать их в формат понятный Покупателю.
Определение компонента платежной расписки.
<!ELEMENT PayReceipt (PackagedContent*)>
ContentSoftwareId CDATA #IMPLIED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент платежной расписки транзакции IOTP. |
| PaymentRef | Содержит ссылку элемента (смотри раздел 3.5) на компонент платежа (смотри раздел 7.9), к которому относится данная расписка. |
| PayReceiptNameRefs | Опционно содержит список значений атрибутов Name элементов Packaged Content, которые образуют расписку. Элементы Packaged Content могут содержать: |
| о | компоненты данных платежной схемы, обмен которыми производится между Кассиром и Покупателем в процессе платежа и/или |
| o | сам компоент платежной расписки. Заметим, что: |
| o | каждый компонент схемы определяет в своем приложении имена элементов Packaged Content, которые должны быть перечислены в этом атрибуте (если они нужны). |
| о | Если компонент платежной схемы содержит элементы Packaged Content, с именами которые совпадают с именем в PayReceiptNameRefs, тогда на такие компоненты платежной схемы должны ссылаться дайджесты в компоненте подписи платежного отклика (если используется такая подпись). |
/p> Программа клиента должна спасать все компоненты, на которые имеются ссылки, с тем чтобы платежная расписка могла быть воспроизведена, если это потребуется.
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Опционно содержит информацию платежной расписки (платежную схему) в виде элементов Packaged Content (смотри раздел 3.7). Определение его содержимого смотри в прилжении платежной схемы. |
Заметим, что должны присутствоать либо атрибут PayReceiptNameRefs, либо элемент PackagedContent или оба.
7.12. Компоент Payment Note
Компонент Payment Note (платежное заывление) содержит дополнительную, несвязанную с платежом информацию, которую Кассир хочет предоставит покупателю. Например, если был произведен отзыв сделки или осуществлен депозит, тогда он может содержать информацию о балансе по завершении перевода. Данные должны дублировать информацию, содержащуюся в компоненте платежной расписки.
Информация, содержащаяся в компоненте Payment Note должна быть отображена или представлена каким-то иным способом покупателю. Для совместимости компонент Payment Note должен поддерживать как минимум содержимое типа "Plain Text", HTML и XML. Его определение представлено ниже.
<!ELEMENT PaymentNote (PackagedContent+) >
<!ATTLIST PaymentNote ID ID #REQUIREDContentSoftwareId CDATA #IMPLIED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент платежной расписки транзакции IOTP. |
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Содержит дополнительную, не связанную с платежом информацию, которую кассир хочет довести до сведения покупателя в виде одного или более элементов Packaged Content (смотри раздел 3.7). |
/p>
7.13. Компонент доставки
Компонент доставки содержит информацию, необходимую для доставки товаров или услуг. Его определение приведено ниже.
<!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
<!ATTLIST Delivery ID ID #REQUIRED
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент доставки транзакции. |
| xml:lang | Определяет язык, используемый атрибутами и дочерними элементами этого компонента, если только атрибут дочернего элемента xml:lang не перепишет это значение. Смотри раздел 3.8. |
| DelivExch |
Индицирует факт наличия в транзакции сообщений, ассоциированных с обменом доставки. Корректные значения: о“Истинно” указывает на наличие обмена доставки. o“Ложно” указывает на отсутствие обмена доставки. |
| DelivAndPayResp |
Индицирует то, чтоблок отклика доставки (смотри раздел 8.11) и блок отклика плптежа (смотри раздел 8.9) находся в одном и том же сообщении IOTP. Корректные значения: o “Истинно” указывает, что оба блока находятся в одном и том же сообщении IOTP и o “Ложно” указывает, что каждый блок размещен в разных сообщениях IOTP. |
На практике комбинирование блока отклика доставкии блока отклика платежа имеет смысл только в случае, когда Продавец, Кассир и Агент доставки принадлежат одной организации, так как:
о Кассир должен иметь доступ к информации компонента Order, с тем чтобы знать что надо доставлять и
o Кассир должен должен быть способен осуществить доставку.
| ActionOrgRef | Ссылка элемента на компонент организации Агента доставки. |
| DeliveryData | Содержит подробности того, как будет осуществляться доставка. Смотри 7.13.1. |
| PackagedContent | Содержит данные "пользователя", определенные для продавца и необходимые агенту доставки в виде одного или нескольких элементов Packaged Content. Смотри раздел 3.7. |
/p>
7.13.1. Элемент Delivery Data
Элемент DeliveryData содержит информацию о том, куда и как должны доставляться товары или услуги. Его определение представлено ниже.
<!ELEMENT DeliveryData (PackagedContent*) >
| <!ATTLIST DeliveryData xml:lang | NMTOKEN #IMPLIED |
| OkFrom CDATA #REQUIRED | OkTo CDATA #REQUIRED |
| DelivMethod NMTOKEN #REQUIRED | DelivToRef NMTOKEN #REQUIRED |
| DelivReqNetLocn CDATA #REQUIRED | SecDelivReqNetLocn CDATA #REQUIRED |
Атрибуты:
| xml:lang | Определяет язык, используемый атрибутами компонента. Смотри раздел 3.8. |
| OkFrom | Дата и время в формате [UTC] после которого Агент доставки может принять на обработку блок запроса доставки (смотри раздел 8.10). |
| OkTo | Дата и время в формате [UTC], до которого Агент доставки может принять на обработку блок запроса доставки. |
| DelivMethod |
Индицирует метод, с помощью которого могут быть доставлены товары или предоставлены услуги. Корректными считаются значения: о Post. Товары будут доставлены по почте или курьером. o Web. Товары будут доставлены электронным образом в комоненте Delivery Note. o Email. Товары будут доставлены электронным образом через e-mail |
о Post, тогда здесь должен быть элемент почтового адреса, содержащий достаточно информации для доставки по почте,
o Web, тогда не нужны никакие специфические требования. Информация будет послана на web-страницу Покупателя,
o Email, тогда здесь должен быть элемент контактной информации с корректным адресом e-mail.
Безопасный запрос доставки предполагает использование безопасного канала, такого как [SSL/TLS] для того чтобы взаимодействовать с кассиром.
Содержимое этого атрибута зависит от транспортного механизма и должно соответствовать регламентациям документа [RFC1738]. Смотри также раздел 3.9.
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Дополнительная информация о доставке в виде одного или несколько элементов Packaged Content (смотри раздел 3.7), предоставляемая агенту доставки продавцу. |
7.14. Информационный компонент доставки Покупателя
Информационный компонент доставки покупателя используется покупателем для спецификации идентификатора, который может быть использован им для идентификации доставки. Его определение приведено ниже:
<!ELEMENT ConsumerDeliveryData EMPTY>
<!ATTLIST ConsumerDeliveryData ID ID #REQUIRED
ConsumerDeliveryId CDATA #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет информационный компонент доставки покупателя для данной транзакции. |
| ConsumerDeliveryId | Идентификатор, специфицированный покупателем, который в случае возврата агентом доставки позволяет покупателю идентифицировать процедуру доставки. |
7.15. Компонент Delivery Note
Компонент Delivery Note (накладная)содержит инструкции о доставке товаров или услу, или саму информацию о доставке. Это информация, которую частное лицо или организация, получающие накладную, могут использовать, когда осуществляется доставка.
Для совместимости компонент Delivery Note должен поддерживать Plain Text, HTML и XML. Его определение представлено ниже.
<!ELEMENT DeliveryNote (PackagedContent+) >
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент Delivery Note транзакции IOTP. |
| xml:lang | Определяет язык, используемый атрибутами или дочерними элементами в рамках данного компонента, если только его значение не будет переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8. |
| DelivHandlerDelivId | Опционный идентификатор, специфицированный Агентом доставки, который в случае возвращения Покупателем в другом компоненте доставки или каким-либо другим способом, позволяет Агенту доставки определить, о какой доставке идет речь. Он необходим для любого компонента доставки, вне зависимости от того содержится ли от в блоке запроса доставки. |
/p>
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Содержит информацию декларации доставки (delivery note) в виде одного или нескольких элементов Packaged Content (смотри раздел 3.7). |
7.16. Компонент Status
Компонент Status содержит информацию состояния бизнес-процесса (успех или неудача) (смотри раздел 4.2). Его определение приведено ниже.
<!ELEMENT Status EMPTY >
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). |
| 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) в блоке запроса, который обрабатывается, тди другая внутренняя ошибка обработки. |
/p> Заметим, что этот код сообщает об обработке блока запроса. Далее, после посылки блока отклика, сопряженного с процессом, может осуществляться асинхронная обработка.
| CompletionCode | Индицирует то, как завершился процесс. Корректные значения CompletionCode приведены ниже вместе с указанием условий, когда атрибут должен присутствовать и указанием возможности восстановления при неудаче. |
может иметь до 14 символов.
| ProcessReference |
Этот опционный атрибут хранит ссылку для процесса, о состоянии которого сообщается. Он может содержать следующие значения: о когда StatusType = Offer, он должен содержать OrderIdentifier компонента Order; o когда StatusType = Payment, он должен содержать PaymentHandlerPayId компонентаданных о схеме платежа; o когда StatusType = Delivery, он должен содержать DelivHandlerDelivId компонента Delivery Note; o когда StatusType = Authentication, он должен содержать AuthenticationId компонента запроса аутентификации. |
Этот атрибут может быть использован внутри блока информационного отклика (смотри раздел 8.13), для того чтобы предоставить код ссылки для транзакции, которя ранее была недоступна.
Например, код упаковки может быть не присвоен в момент получения отклика доставки. Однако, если покупатель поздее выдаст запрос состояния транзакции, Агент доставки может проставить код упаковки в атрибут сообщения информационного отклика и послать его Покупателю.
| StatusDesc | Опционное текстовое описание текущего состояния процесса на языке, заданном атрибутом xml:lang. |
7.16.1. Коды завершения предложения
Код завершения является единственно необходимым, если атрибут ProcessState = Failed
(неудача). Ниже следующая таблица содержит допустимые значения CompletionCode, которые могут использоваться и индицировать, возможно ли восстановление процесса. Рекомендуется, чтобы там, где это необходимо для дальнейшего разъяснения, использовался атрибут StatusDesc.
Восстановление может осуществить Покупатель, повторно предложив блок отклика аутентификации с правильными данными.
| 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 | Невосстановимый таймаут. Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно. |
/p> Если оплата не зависит от вида платежа, тогда восстановление для некоторых видов кода завершения возможно для покупателя, который может выбрать другой вид платежа или новый платежный инструмент для того же вида платежа. Заметим, что это может потребовать замены кассира. Здесь применимы следующие коды: BrandNotSupp, PaymtCancelled, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument и Unspecified.
Восстановление прооцедуры платежа при покупках, зависящих от вида платежа возможно только в случае, если компонент выбора вида платежа, посланный продавцом покупателю, не изменился. На практике это означает, что должны использоваться тот же элемент вида платежа, платежный протокол и сумма. Единтвенно что можно изменить – это платежный инструмент. Любые другие изменения будут неприемлемы.
7.16.3. Коды завершения доставки
Таблица, представленная ниже, содержит допустимые значения атрибута 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). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно. |
/p> Восстановление при неудаче или в случае частично завершенной доствки невозможно. Покупатель для получения текущего состояния транзакции должен использовать информационный запрос (смотри раздел 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). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно. |
/p>
7.16.5. Неопределенные коды завершения
Код завершения требуется только тогда, когда атрибут ProcessState = Failed. Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
| Значение | Описание |
| InMsgHardError | Серьезная ошибка во взодном сообщении (Input Message Hard Error). Тип блока запроса не может быть идентифицирован или является несовместимым. Следовательно никакой однодокументный обмен не может быть идентифицирован. Это может вызвать серьезную ошибку в транзакции. |
7.16.6. Коды завершения информационного запроса транзакции
Код завершения требуется только тогда, когда атрибут ProcessState = Failed. Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
| Значение | Описание |
| UnAuthReq | Неавторизованный запрос (Unauthorised Request). Получатель запроса состояния транзакции отказывается откликаться на запрос. |
7.17. Компонент данных торговой роли
Компонент данных торговой роли содержит данные, которые должны быть пересланы между торговыми ролями вовлеченными в транзакцию.
Компоненты торговой роли определяют:
o организацию, которая сформировала компонент и
o организацию, которая его получила.
Они являются первыми сформированными и включенными в блок “отклик” и затем скопированных в соответствующий блок “запрос”. Например, кассиру может оказаться нужно проинформировать агента доставки о том, что платеж через кредитную карточку авторизован (but not captured). В другом примере продавцу может понадобиться предоставить кассиру некоторую специфическую информацию о Покупателе.
Его определение представлено ниже.
<!ELEMENT TradingRoleData (PackagedContent+) >
<!ATTLIST TradingRoleData ID ID #REQUIRED
OriginatorElRef NMTOKEN #REQUIREDDestinationElRefs NMTOKENS #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент данных торговой роли транзакции IOTP. |
| OrginatorElRef | Содержит ссылку элемента на компонент Organisation организации, которая создала компонент данных о торговой роли и включила его в блок отклика (напр., блок отклика предложения или платежа). |
| DestinationElRefs | Содержит ссылку элемента на компоненты Organisation организации, которая получила компонент данных о торговой роли в блоке запроса (напр., блоков запроса платежа или доставки). |
| PackagedContent | Содержит данные, которыые должны быть пересланы между торговыми ролями в виде одного или нескольких элементов PackagedContent, смотри раздел 3.7. |
7.17.1. Кто получает компонент данных о торговой роли
Ниже описаны правила, которые определяют, что следует делать с компонентами данных торговой роли.
Когда бы ни был получен компонент данных торговой роли в блоке "Отклик", идентифицировать компоненты Organisation, которые должны получить его, как идентифицированные атрибутом DestinationElRefs.
Когда бы ни был послан блок "Запрос", проверить, был ли он послан одной из организаций (адресат), идентифицированной атрибутом. Если это так, включить в блок "Запрос" следующее:
| - компонент данных о торговой роли, а также, | |
| - компонент Organisation, идентифицированной атрибутом OriginatorElRef. |
7.18. Компонент типа информационного запроса
Компонент типа информационного запроса содержит информацию, которая указывает тип процесса, о котором получен запрос. Его определение представлено ниже.
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType ID ID #REQUIREDType NMTOKEN #REQUIRED
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). |
/p>
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, например:
<Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
<Parameter type='AlgorithmRef'>A2</Parameter> </Algorithm>
<Algorithm ID=A2 type="digest" name="urn:fips:sha1"> </Algorithm>
<Algorithm ID=A3 type="signature" name="urn:ibm:hmac">
Элемент 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; | |
| каждый из компонентов списка видов платежа; |
из блока отклика предложения:
| компонент Order; | |
| каждый из компонентов Payment; | |
| компонент Delivery; | |
| каждый из компонентов запроса аутентификации; | |
| любой компонент данных о торговой роли. |
/p> Подпись отклика предложения должна также содержать элементы дайджеста для компонентов, которые описывают каждую из организаций, которая может или будет нуждаться в верификации подписи. Это включает в себя:
если продавец получил блок выбора 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 представлено ниже.
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIREDErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED Severity (Warning|TransientError|HardError) #REQUIRED
Атрибуты:
| 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. |
/p> Если атрибут Severity не равен TransientError, тогда значение этого атрибута игнорируется.
| SwVendorErrorRef | Этот атрибут является ссылкой, чье значение установлено поставщиком/разработчиком программы, которая сформировала компонент Error. Он должен содержать данные, которые позволяют поставщику идентифицировать точную позицию в его прогрпмме и установить причины, которые вызвали сообщение об ошибке. Смотри также атрибут SoftwareID Id-элемента сообщения в блоке ссылки транзакции (раздел 3.3). |
| ErrorLocation | Идентифицирует Id транзакции IOTP сообщения с ошибкой и, если возможно, элемент и атрибут сообщения, который вызвал формирование компонента Error. |
| 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). |
7.21.1.2. Severity = переходная ошибка
Если приложение генерирует сообщение с компонентом Error, где атрибут Severity = TransientError, тогда в сообщение должен быть только один компонент Error. Кроме того, должен присутствовать атрибут MinRetrySecs. Если сообщение, уведомляющее об ошибке получено с компонентом Error, где Severity
= TransientError тогда:
если атрибут MinRetrySecs присутствует и имеет правильное значение, тогда следует использовать данную величину MinRetrySecs. В противном случае, если MinRetrySecs отсутствует или имеет неверное значение, тогда:
Проверить, что только один элемент 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]. |
| ElUnexpected |
Нестандартный элемент . Несмотря на то что документ XML сформирован правильно и корректен, присутствует элемент, который не является стандартным для данного контекста согласно правил и ограничениям, содержащимся в данной спецификации. |
| ElNotSupp | Элемент не поддерживается . Несмотря на то что документ XML сформирован правильно и корректен, присутствует элемент, который: o согласуется с правилами и ограничениями данной спецификации, но o не поддерживается приложением IOTP, которое обрабатывает IOTP-сообщение. |
| ElMissing | Элемент отстутствует . Несмотря на то что документ XML сформирован правильно и корректен, отсутствует элемент, который должен присутствовать, если следовать правилам и ограничениям данной спецификации. |
/p> В этом случае следует установить PackagedContent компонента Error соответствующим типу пропущенного элемента.
| ElContIllegal |
Содержимое элемента не верно . Несмотря на то что документ XML сформирован правильно и корректен, элемент Content содержит значения, которые не согласуются с правилами и ограничениями данной спецификации. |
| EncapProtErr |
Ошибка инкапсулированного протокола . Несмотря на то что документ XML сформирован правильно и корректен, PackagedContent элемента содержит данные инкапсулированного протокола, которые неверны. |
| AttUnexpected |
Нестандартный атрибут . Несмотря на то что документ XML сформирован правильно и корректен, присутствие такого атрибута в данном контексте не предусмотрено и не согласуются с правилами и ограничениями данной спецификации. |
| AttNotSupp |
Атрибут не поддерживается . Несмотря на то что документ XML сформирован правильно и корректен, и приутствие атрибута элемента согласуется с правилами и ограничениями данной спецификации, он не поддерживается конкретной программной реализацией, которая обрабатывает сообщение IOTP. |
| AttMissing |
Атрибут отсутствует . Несмотря на то что документ сформирован правильно и корректен, отсутствует атрибут, который согласно правилам и ограничениям данной спецификации должен присутствовать. |
| AttValIllegal | Не верно значение атрибута . Атрибут содержит значение, которое не согласуется с правилами и ограничениями данной спецификации. |
| AttValNotRecog |
Значение атрибута не распознано . Атрибут содержит значение, которое приложение IOTP, обрабатывающее сообщение, не смогло распознать. |
| MsgTooLarge |
Сообщение имеет слишком больую длину . Сообщение слишком велико для приложения, его обрабатывающего. |
| ElTooLarge |
Элемент слишком велик . Элемент слишком велик для приложения, его обрабатывающего. |
| ValueTooSmall |
Значение слишком мало . Значение всего или части элемента Content или атрибута, хотя и верно, но слишком мало. |
| ValueTooLarge |
Значение слишком велико . Значение всего или части элемента Content или атрибута, хотя и верно, но слишком велико. |
| ElInconsistent | Элемент не согласован . Несмотря на то что документ сформирован правильно и корректен, согласно правилам и ограничениям данной спецификации: о содержимое элемента не согласуется с содержимым других элементовили их атрибутов или о значение атрибута не согласуется со значением одного или нескольких других атрибутов. |
/p> В этом случае следует создать элементы ErrorLocation, которые определяют все несогласованные атрибуты или элементы.
| TransportError |
Транспортная ошибка (Transport Error). Этот код ошибки используется для индикации проблем с транспортным механизмом, которые приводят к потере сообщения. Она обычно ассоциируется с переходной ошибкой. Объяснение переходной ошибки содержится с атрибуте ErrorDesc. Значения, которые могут использоваться в ErrorDesc с TransportError специфицированы в приложении IOTP для транспортного механизма. |
| MsgBeingProc |
Сообщение обрабатывается (Message Being Processed). Этот код ошибки используется только с серьезностью (Severity) переходных ошибок. Код указывает, что предыдущее сообщение обрабатывается и, если в орговоренное время, заданное атрибутом MinRetrySecs, не получено отклика, оригинальное сообщение следует послать вновь. |
| SystemBusy |
Система занята (System Busy). Этот код ошибки используется только с серьезностью (Severity) переходных ошибок. Он указывает, что сервер, который получил сообщение, в настоящее время занят и обработать сообщение не может. Если в орговоренное время, заданное атрибутом MinRetrySecs, не получено отклика, оригинальное сообщение следует послать вновь. |
| UnknownError | Неизвестная ошибка . Индицирует, что транзакция не может завершиться по неидентифицированной причине. Атрибут ErrorDesc следует использовать для индикации природы проблемы. Эта ошибка может быть применена для указания, например, внутренней ошибки оконечного сервера или процесса клиента. |
7.21.3. Элемент положения ошибки
Элемент Error Location указывает элемент и опционно атрибут в сообщении, с которым ассоциируется ошибка. Он содержит ссылку на сообщение IOTP, торговый блок, торговый компонент, элемент и атрибут, где обнаружена ошибка.
<!ELEMENT ErrorLocation EMPTY >
| <!ATTLIST ErrorLocation ElementType | NMTOKEN #REQUIRED |
| IotpMsgRef NMTOKEN #IMPLIED | BlkRef NMTOKEN #IMPLIED |
| CompRef NMTOKEN #IMPLIED | ElementRef NMTOKEN #IMPLIED |
Атрибуты:
| ElementType | Имя типа элемента, где обнаружена ошибка. Например, если элемент декларирован как <!ELEMENT Org, тогда его имя - "Org". |
| IotpMsgRef | Значение ID-атрибута Id-компонента сообщения (смотри раздел 3.3.2), к которому относится компонент Error. |
| BlkRef | Если ошибка ассоциирована со специфическим торговым блоком, тогда это значение ID-атрибута торгового блока, где обнаружена ошибка. |
| CompRef | Если ошибка ассоциирована со специфическим торговым компонентом, тогда это значение ID-атрибута торгового компонента, где обнаружена ошибка. |
| ElementRef | Если ошибка ассоциирована со специфическим элементом торгового компонента, тогда, если элемент имеет атрибут с типом (смотри [XML]) "ID", тогда это значение данного атрибута. |
| AttName | Если ошибка ассоциирована со значением атрибута, тогда это имя данного атрибута. В этом случае PackagedContent компонента Error должен содержать значение атрибута. |
8. Торговые блоки
Торговые блоки являются дочерними элементами IOTP-сообщения верхнего уровня, которое послано в форме [XML]-документа от одного партнера торговой операции к другому.
Каждый трговый блок состоит из одного или более торговых компонентов (смотри раздел 7). Это проиллюстрировано на диаграмме.
Рис. .16. Торговые блоки
Торговые блоки определены как часть определения сообщения IOTP (смотри раздел 3.1.1). Определение элемента сообщения IOTP представлено ниже:
<!ELEMENT IotpMessage
) >
Далее в данном разделе определены торговые блоки данной версии IOTP. Это:
Блок запроса аутентификации (Authentication Request Block)
Блок отклика аутентификации (Authentication Response Block)
Блок состояния доставки
Блок Cancel
Блок запроса доставки
Блок отклика доставки
Блок Error
Блок информационного запроса
Блок информационного отклика
Блок отклика Offer
Блок платежного обмена
Блок платежного запроса
Блок платежного отклика
Блок подписи
Блок опций торгового протокола
Блок выьора TPO
Блок ссылок транзакции определен в разделе 3.3.
8.1. Блок опций торгового протокола
Торговый блок TPO содержит опции, которые применяются в транзакции IOTP. Определение торгового блока TPO представлено ниже.
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* )>
<!ATTLIST TpoBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок опций торгового протокола транзакции IOTP (смотри раздел 3.4). |
| ProtocolOptions | Компонент протокольных опций (смотри раздел 7.1) определяет опции, которые распространяются на всю транзакцию IOTP (смотри раздел 9). |
| BrandList | Этот компонент списка видов платежа содержит один или более видов протоколов и типов платежа, которые можно выбрать (смотри раздел 7.7). |
| Org | Компоненты Organisation (смотри раздел 7.6) идентифицируют организации и их роли в транзакции IOTP. Роли и организации, которые должны присутствовать, зависят от конкретного типа транзакции. Определения каждой транзакции смотри в разделе 9. |
компонент протокольных опций;
компонент Organisation с торговой ролью Продавца;
компонент Organisation с торговой ролью Покупателя;
опционно, компонент организации торговой ролью DeliverTo, если транзакция предполагает доставку;
компоненты списка видов платежа для каждого платежа транзакции;
компоненты Organisation для Кассира, включенного в транзакцию;
опционно, компоненты Organisation для Агента доставки (если имеется) транзакции;
дополнительные компоненты Organisation, которые Продавец захочет включить. Например.
8.2. Блок выбора TPO
Блок выбора TPO содержит результаты выбора, сделанного из списка, содержащегося в блоке протокольных опций (смотри раздел 8.1). Определение блока выбора TPO предлагается ниже.
<!ELEMENT TpoSelectionBlk (BrandSelection+) >
<!ATTLIST TpoSelectionBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок выбора TPO транзакции IOTP. |
| BrandSelection | Идентифицирует выбор вида платежаи платежного протокола, которы следует использовать при оплате в транзакции IOTP. Имеется один компонент выбора вида платежа (смотри раздел 7.8) для каждого предстоящего платежа транзакции IOTP. |
8.3. Блок отклика Offer
Блок отклика Offer содержит подробности о товарах, услугах, сумме, инструкций доставки или финансовых операциях, которые должны быть осуществлоены. Его определение дано ниже.
<!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*)>
<!ATTLIST OfferRespBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок отклика Offer транзакции. |
| Status | Содержит статусную информацию об успехе или неудаче подготовки предложения (смотри раздел 4.2). Заметим, что в блоке отклика Offer, значения ProcessState NotYetStarted или InProgress являются нелегальными. |
| Order | Компонент Order содержит подробности о товарах, услугах или финансовой операции, которая имеет место, смотри раздел 7.5. |
/p> Компонент Order должен присутствовать, если только атрибут ProcessState компонента Status не равен Failed.
| Payment | Компоненты Payment содержат информацию о платежах, которые надлежит произвести, смотри раздел 7.9. |
| Delivery | Компонент Delivery содержит детали предстоящей доставки (смотри раздел 7.13). |
| TradingRoleData | Компонент информации о торговой роли содержит данными должны обменяться торговые роли, вовлеченные в транзакцию (смотри раздел 7.17). |
компонент Order транзакции;
компоненты Payment для каждой проплаты транзакции;
компонент Delivery транзакции (если предусмотрено).
8.4. Блок запроса аутентификации
Блок запроса аутентификации содержит данные, которые используются одной из торговых ролей для получения информации и опционно для аутентификации другой торговой роли. Этот блок содержит:
информацию о том, как аутентифицировать себя и/или
запрос о дополнительной информации об организации, которую надлежит аутентифицировать.
Его определение предагается ниже.
<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?)>
<!ATTLIST AuthReqBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок запроса аутентификации транзакции. |
| AuthReq | Каждый компонент запроса аутентификации (смотри раздел 7.2) описывет альтернативный путь, с помощью которого получатель запроса аутентификации может себя аутентифицировать, генерируя компонент отклика аутентификации (смотри раздел 7.3). |
Если нет ни одного компонента запроса аутентификации, это означает, что блок аутентификационного запроса запрашивает присылку компонентов Organisation, как это специфицировано в компоненте информационного запроса торговой роли.
| TradingRoleInfoReq | Компонент информационного запроса торговой роли (смотри раздел 7.4) содержит список торговых ролей, данные о которых запрашиваются. |
/p> В аутентификационном блоке должен быть по крайней мере один компонент (аутентификационного запроса или информационного запроса торговой роли), в противном случае имеет место ошибка.
8.5. Блок отклика аутентификации
Блок отклика аутентификации содержит отклик, который является результатом обработки блока запроса аутентификации. Его определение представлено ниже.
<!ELEMENT AuthRespBlk (AuthResp?, Org*) >
<!ATTLIST AuthRespBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок отклика аутентификации транзакции. |
| AuthResp | Опционный компонент аутентификационного отклика, который содержит результаты обработки компонента запроса аутентификации – смотри раздел 7.3. |
| Org | Опционные компоненты Organisation, которые содержат информацию, соответствующую торговым ролям, как это запрошено атрибутом TradingRoleList компонента информационного запроса торговой роли. |
8.6. Блок состояния аутентификации
Блок состояния аутентификации индицирует успех или неудачу верификации блока отклика аутентификации аутентификатором. Его определение представлено ниже.
<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок состояния аутентификации транзакции. |
| Status | Содержит статусную информацию об успехе или неудаче аутентификации (смотри раздел 4.2). |
8.7. Блок платежного запроса
Блок платежного запроса содержит информацию, которая запускает процедуру платежа. Его описание представлено ниже.
<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*, TradingRoleData*)>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок платежного запроса транзакции. |
| Status | Содержит компоненты Status (смотри раздел 7.13) откликов на шаги (напр., отклика Offer и/или Payment), от которых данный шаг зависит. Он используется чтобы индицировать успех или неудачу этих шагов. Платеж может состояться лишь тогда, когда все предыдущие шаги были успешными. |
| BrandList | Компонент списка видов платежа содержит список из одного или более видов платежа и протоколов, которые могут быть выбраны (смотри раздел 7.7). |
| BrandSelection | Идентифицирует выбор вида платежа, платежного протокола и Кассира, которые должны быть использованы при оплате в данной транзакции. Имеется один компонент выбора вида платежа (смотри раздел 7.8) для каждой проплаты, которую следует выполнить в процессе транзакции. |
| Payment | Компоненты Payment содержит информацию о платеже, который выполняется, смотри раздел 7.9. |
| PaySchemeData | Компонент Payment Scheme содержит специфические данные о платежной схеме, смотри раздел 7.10. |
| Org | Компонент Organisation содержит подробности об организациях, вовлеченных в платеж (смотри раздел 7.6). Присутствие организаций зависит от транзакции и данных, которые должны быть подписаны. Смотри раздел 6. |
| TradingRoleData | Компонент данных о торговой роли содержит информацию, которая нужна для пересылки между торговыми ролями, вовлеченными в транзакцию (смотри раздел 7.17). |
/p> Блок платежного запроса должен содержать:
Компонент Organisation с торговой ролью продавца;
Компонент Organisation с торговой ролью Покупателя;
Компонент Payment для платежа;
Компонент Brand List;
Компонент выбора вида платежа из списка;
Компонент Organisation для Кассира, осуществляющего платеж;
Компонент Organisation (если такоая имеется) для организации, которая выполнила предыдущий шаг, например другой Кассир;
Компонент Organisation для организации, которая выполняет следующий шаг. Это может быть, например, Агент доставки или Кассир;
Компонент Organisation для любых дополнительных организаций, которые Продавец включил в блок отклика Offer;
Опционный компонент данных платежной схемы, если это требуется методом платежа, определенном в приложении IOTP;
Любой компонент информации о платежной роли, который может потребоваться (смотри раздел 7.17.1).
8.8. Блок платежного обмена
Блок платежного обмена содержит специфические данные о платежной схеме, которыми обмениваются две торговые роли в рамках сделки. Его определение представлено ниже.
<!ELEMENT PayExchBlk (PaySchemeData+)>
<!ATTLIST PayExchBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок платежного обмена транзакции. |
| PaySchemeData | Этот торговый компонент содержит специфические данные о платежной схеме, смотри раздел 7.10. |
8.9. Блок платежного отклика
Этот блок платежного отклика содержит информацию о состоянии платежа, опционной платежной расписке и опционные сообщения платежного протокола. Его определение представлено ниже.
<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
PaymentNote?, TradingRoleData*)>
<!ATTLIST PayRespBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок платежного отклика транзакции. |
| Status | Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) платежа. Заметим, что в блоке платежного отклика, значения ProcessState NotYetStarted или InProgress являются нелегальными. |
| PayReceipt | Содержит специфические данные о платежной схеме, которые могут быть использованы для верификации произведенного платежа. Смотри раздел 7.11. Он должен присутствовать, если атрибут ProcessState компонента Status равен CompletedOk. Атрибут PayReceipt является опционным. |
| PaySchemeData | Содержит специфические данные о платежной схеме, например, о сообщениях платежного протокола. Смотри также раздел 7.10. |
| PaymentNote | Содержит дополнительную, несвязанную с платежом информацию, которую кассир желает предоставить покупателю. Например, если выполнен отзыв сделки или осуществлен депозит, он может содержать данные о полученном балансе на счету, после того как данная операция завершена. Смотри раздел 7.12. |
| TradingRoleData | Компонент информации о торговой роли содержит данные, которые нужны для обмена между ролями, участвующими в транзакции (смотри раздел 7.17). |
/p>
8.10. Блок запроса доставки
Блок запроса доставки содержит подробности о товарах или услугах, которые должны быть предоставлены вместе с подписью, которая позволяет удостовериться, что доставка была авторизована. Его определение приведено ниже.
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
ConsumerDeliveryData?, TradingRoleData*)>
<!ATTLIST DeliveryReqBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок запроса доставки транзакции. |
| Status | Содержит компоненты Status (смотри раздел 7.13) откликов на шаги (напр., платежный отклик), от которых данный шаг зависит. Он используется чтобы индицировать успех или неудачу этих шагов. Доставку следует осуществлять только если все прдыдущие шаги завершились успешно. |
| Order | Компонент Order содержит подробности о товарах, услугах или финансовых операциях, которые имеют место, смотри раздел 7.5. Комоненты Organisation (смотри раздел 7.6) идентифицируют организации их роли. |
| Org | Транзакция IOTP. Роли и организации, которые должны присутствовать зависят от конкретного типа транзакции. Описания транзакций смотри в разделе 9. |
| Delivery | Компонент Delivery содержит подробности доставки, которую следует осуществить (смотри раздел 7.13). |
| ConsumerDeliveryData | Опционный. Содержит идентификатор, специфицированный Покупателем, который в случае возвращения Агентом доставки позволяет покупателю определить, о какой доставке идет речь. |
| TradingRoleData | Компонент данных о торговой роли содержит информацию, которая нужна при обмене между двумя торговыми ролями в процессе транзакции (смотри раздел 7.17). |
Компонент Organisation с торговой ролью Продавца;
Компонент Organisation для торговых ролей Покупателя и DeliverTo;
Компонент Delivery;
Компонент Organisation для Агента доставки. В частности компонент Organisation, идентифицированный атрибутом ActionOrgRef компонента Delivery;
Компонент Organisation (если имеется) для организации, которая осуществила предыдущий шаг, например Кассира;
Компоненты Organisation для любой дополнительной организации, которую Продавец включил в блок отклика Offer;
Любые компоненты данных о торговой роли, которая может потребоваться (смотри раздел 7.17.1).
8.11. Блок отклика доставки
Блок отклика доставки содержит Delivery Note, содержащую подробности о том как будут доставляться товары. Его определение представлено ниже. Заметим, что в блоке отклика Delivery элемент состояния доставки с DeliveryStatusCode равным NotYetStarted или InProgress является нелегальным.
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote)>
<!ATTLIST DeliveryRespBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок отклика доставки транзакции. |
| Status | Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) доставки. Заметим, что в блоке отклика Delivery, ProcessState равный NotYetStarted или InProgress считается нелегальным. |
| DeliveryNote | Компонент Delivery Note содержит подробности о том, как будут доставляться товары или услуги (смотри раздел 7.15). |
8.12. Торговый блок информационного запроса
Торговый блок информационного запроса содержит компоненттип запроса и опционно платежной схемы.
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет торговый блок информационного запроса транзакции. |
| InquiryType | Компонент тип информационного запроса (смотри раздел 7.18), который содержит код типа запроса. |
| PaySchemeData | Компонент платежная схема (Payment Scheme) (смотри раздел 7.10), который содержит специфические данные конкретных информационных запросов о платежной схеме. Он присутствует, когда атрибут Type компонента типа запроса равен Payment. |
8.13. Торговый блок информационного отклика
Торговый блок информационного отклика содержит компонент Status и опционно компонент Payment Scheme. Его целью является осуществление запроса о текущем состоянии транзакции или сервера.
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?)>
<!ATTLIST InquiryRespBlk ID ID #REQUIRED
LastReceivedIotpMsgRef NMTOKEN #IMPLIED
LastSentIotpMsgRef NMTOKEN #IMPLIED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет торговый блок информационного отклика транзакции. |
| LastReceivedIotpMsgRef | Содержит ссылку элемента (смотри раздел 3.5) на Id-компонент (смотри раздел 3.3.2) последнего сообщения, которое получил данный сервер от покупателя. Если до этого не получено от покупателя ни одного сообщения, этот атрибут должен содержать значение (Null). Данный атрибут предназначен для отладочных целей. |
| LastSentIotpMsgRef | Содержит ссылку элемента (смотри раздел 3.5) на Id-компонент (смотри раздел 3.3.2) последнего сообщения, которое послал данный сервер покупателю. Если до этого не послано ни одного сообщения покупателю, данный атрибут должен содержать значение (Null). Этот атрибут предназначен для отладочных целей. |
8.14. Блок запроса Ping
Блок запроса Ping используется, чтобы определить, работает ли сервер и является ли криптография совместимой.
Определение блока запроса Ping предложено ниже.
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk ID ID #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет запрос Ping торгового блока транзакции. |
OrgОпционные компоненты Organisation (смотри раздел 7.6).
Если нет ни одного компонента Organisation, тогда запрос Ping является анонимным и служит для проверки, работает ли сейчас сервер.
Однако, если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping хочет проверить, могут ли быть обработаны цифровые подписи.
В этом случае отправитель включает:
Компонент Organisation, который идентифицирует сам себя, специфицируя торговую роль (или роли), которую он исполняет в транзакции (Продавец, Кассир, и т.д.)
Компонент Organisation, который идентифицирует получателя сообщения.
Эти компоненты используются для формирования подписи блока отклика Ping.
8.15. Блок отклика Ping
Блок отклика Ping предоставляет результат выполнения запроса Ping. Он содержит компонент Organisation, который идентифицирует отправителя отклика Ping.
Если запрос Ping, для которого этот блок является откликом, содержал компоненты Organisation, тогда он также содержит эти компоненты Organisation.
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk ID ID #REQUIRED
PingStatusCode (Ok | Busy | Down) #REQUIRED
SigVerifyStatusCode (Ok | NotSupported | Fail) #IMPLIED
xml:lang NMTOKEN #IMPLIEDPingStatusDesc CDATA #IMPLIED>
Атрибуты:
ID |
Идентификатор, который однозначно определяет торговый блок запроса Ping транзакции. |
| PingStatusCode |
Содержит код, который показывает состояние программы отправителя, которая обрабатывает IOTP-сообщения. Допустимыми значениями являются: o Ok. Сервис работает нормально, включая проверку подписей. o Busy. Все идет хорошо, но возможны некоторые задержки. o Down. Сервер не вполне функционален, но все же может выдать отклик Ping. |
SigVerifyStatusCode |
Заключает в себе код, который показывает состояние проверки подписи. Он присутствует только когда сообщение, содержащее блок запроса Ping имеет также блок Signature. Допустимы следующие значения: o Ok. Веоификация подписи прощла успешно. o NotSupported. Получатель блока запроса Ping не поддерживает валидацию подписей. o Fail. Верификация подписи не прошла. |
Xml:lang |
Определяет язык, использованный в PingStatusDesc. Присутствует тогда, когда имеется PingStatusDesc. |
PingStatusDesc |
Содержит короткое описание состояния сервера, который поылает этот блок отклика Ping. Сервер, если его разработчики хотят, может использовать этот атрибут для посылки более детальной информации, чем содержится в PingStatusCode, он может использоваться, например, для отладрчных целей. |
/p> Cодержимое:
Org |
Компоненты Organisation (смотри раздел 7.6). |
Значения статусного кода Ping не включают в себя такие значения как Fail, так как, когда программа, получающая сообщение запроса Ping, не работает, не будет послано никакого отклика Ping.
8.16. Блок подписи
Блок Signature содержит один или более компонентов Signature и соответствующих сертификатов (если требуется), которые подтверждают данные в рамках данной транзакции. Определение компонента Signature и сертификатов содержится в статье "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Описание их применения в IOTP можно найти в разделах 7.19 и 7.20.
Определение блока Signature представлено ниже:
<!ELEMENT IotpSignatures (Signature+, Certificate*) >
<!ATTLIST IotpSignatures ID ID #IMPLIED >
Атрибуты:
Cодержимое:
| Signature | Компонент Signature. Смотри раздел 7.19. |
| Certificate | Компонент Certificate. Смотри раздел 7.20. |
8.16.1. Блок подписи в отклике предложении
Блок подписи, который содержится в том же сообщении, что и блок отклика Offer, несет в себе только компонент подписи отклика Offer (смотри раздел 7.19.2).
8.16.2. Блок подписи в платежном запросе
Блок Signature, который содержится в том же сообщении, что и блок платежного запроса, содержит в себе:
Компонент подписи отклика Offer (смотри раздел 7.19.2) и
Если поатеж зависит от предыдущего шага (как указано атрибутом StartAfter компонента Payment), тогда компонент подписи платежной расписки (смотри раздел 7.19.3) генерируется на предыдущем этапе (шаге).
8.16.3. Блок подписи в платежном отклике
Блок подписи, который содержится в том же сообщении, что и блок платежного отклика, содержит только компонент подписи платежной расписки (смотри раздел 7.19.3), сформированной на этом этапе (шаге).
8.16.4. Блок подписи в запросе доставки
Блок подписи, который содержится в том же сообщении, что и блок запроса доставки, содержит:
Компонент подписи отклика Offer (смотри раздел 7.19.2) и
Компонент подписи платежной расписки (смотри раздел 7.19.3), сформированный на предшествующем шаге.
8.16.5. Блок подписи в отклике доставки
Блок Signature, который содержится в том же сообщении, что и блок отклика доставки, содержит только компонент подписи отклика Delivery (смотри раздел 7.19.4), сформированный на этом шаге.
8.17. Блок ошибки
Торговый блок Error содержит один или более компонентов Error (смотри раздел 7.21), которые несет в себе информацию о технических ошибках (смотри раздел 4.1) в сообщении IOTP, полученном одной из торговых ролей, вовлеченных в сделку.
Ниже представлены две фразы, которые используются в описании торгового блока Error:
ошибочное сообщение. Сообщение IOTP, которое содержит или является причиной ошибки какого-то рода;
сообщение, опровещающее об ошибке. Сообщение IOTP, которое содержит торговый блок Error, описывающий ошибку, найденную в сообщении.
Торговый блок Error может содержаться в любом сообщении, уведомляющем об ошибке. Реакция на такое сообщение зависит от серьезности (severity) ошибки. Разъяснения различных значений серьезности ошибки (и сопряженных с ними действий) дано в определении компонента Error.
Несмотря на то что торговый блок Error может уведомлять о многих различных ошибках, используя несколько компонентов Error, разработчики приложений могут и не поддерживать такую возможность.
Структура торгового блока Error представлена ниже.
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок Error транзакции. |
| ErrorComp | Компонент Error (смотри раздел 7.21), который содержит информацию об индивидуальной технической ошибке. |
| PaySchemeData | Опционный компонент Payment Scheme (смотри раздел 7.10), который содержит описание платежной схемы. |
/p>
8.18. Блок Cancel
Блок Cancel используется одной торговой ролью чтобы информировать остальных о том, что транзакция аннулируется. Пример использования включает в себя:
Роль Покупателя, информирующую других о том, что он не собирается продолжать транзакцию. Это позволяет серверу завершить транзакцию, не дожидаясь таймаута.
Роль, отличная от покупателя, информирует Покупателя о том, что транзакция останавливается. В этом случае Покупатель вряд ли повторно пошлет предыдущее сообщение в предположении, что оно не было получено.
Его определение имеет вид.
<!ELEMENT CancelBlk (Status) >
<!ATTLIST CancelBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок Cancel транзакции. |
| Status | Содержит статусную информацию, указывающую, что транзакция была аннулирована. |
9. Транзакции IOTP
Базовая версия протокола IOTP поддерживает три типа транзакций. Среди них:
Транзакции аутентификации IOTP, которые поддерживают аутентификацию одного партнера сделки другим партнером и/или получение информации о другой торговой роли.
Транзакции IOTP, которые включают в себя один или более платежей. В частности:
- Депозит
- Покупка
- Возврат денег
- Отзыв сделки
- Обмен ценностями
Транзакции IOTP предназначенные для проверки корректности функционирования инфраструктуры. В частности:
- Транзакция запроса состояния и
- Ping
Хотя транзакции аутентификации могут выполняться сами по себе, опционно любая платежная операция может предшествоваться аутентификацией. Остальная часть данного раздела поделена на две части, где описывается:
Аутентификационные и платежные транзакции (аутентификация, депозит, покупка, возврат денег, аннулирование сделки и обмен ценностями)
Инфраструктурные транзакции (транзакция запроса состояния и Ping), которые предназначены для поддержки запросов о том, успешно ли прошла транзакция или правильно ли работает сервер торговой роли.
9.1. Транзакции аутентификации и платежа
Транзакции, имеющие отношение к аутентификации и платежу состоят из шести документальных обменов, которые объединяются в последовательности, чтобы реализовать определенную транзакцию.
Вообще имеется теснаое но не точное соответствие между документальным и торговым обменами. Главное отличие заключается в том, что некоторые документальные обмены включают в себя часть или все два торговых обменов одновременно для того чтобы минимизировать число IOTP-сообщений, посылаемых через Интернет.
Эти шесть документальных обменов включают в себя:
Аутентификация. Это прямая реализация аутентификации торгового обмена;
Предложение (Offer), зависимое от вида платежа. Это торговый обмен предложения, объединенный с платежным обменом выбора вида платежа. Его целью является обеспечение Продавца информацией о выборе вида платежа;
Предложение, не зависимое от вида платежа. Это также торговый обмен предложения (Offer). Однако в этом случае содержимое отклика Offer не зависит от выбора вида платежа;
Платеж. Это непосредственная реализация платежной части торгового обмена;
Доставка. Это прямая реализация обмена доставки;
Доставка с платежом. Это реализация совмещеных торговых обменов платежа и доставки.
Эти документальные обмены скомбинированы вместе в различные последовательности, чтобы реализовать каждую из транзакций. Способ, которым они могут комбинироваться проиллюстрирован на рис. .17.
Рис. .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. | Первая организация проверяет статусный блок и, если все в порядке, завершает транзакцию. |
/p> Рис. .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 | аутентификация не прошла, тогда аутентифицируемый должен быть оповещен о неудаче, а процесс остановлен. |
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;
следующие компоненты блока запроса аутентификации:
| - компонент запроса аутентификации; | |
| - компонент информационного запроса о торговой роли; |
Не следует предполагать, что все торговые роли могут поддерживать цифровую подпись данных. В частности не нужно думать, что эта опция поддерживается Покупателем.
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).
M
M
… продолжение ...
Рис. .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, чтобы сформировать следующее сообщение транзакции и послать его соответствующей торговой роли. |
Рис. .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), со следующими ролями:
Если транзакция 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 (снабдив его, если требуется, подписью) соответствующей торговой роли |
/p> Рис. .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 для выполняемого платежа |
одного компонента выбора вида платежа, т.e. компонента выбора вида платежа, где атрибут BrandListRef указывает на список видов платежа. Этот компонент может быть:
опционного компонента платежной схемы (смотри раздел 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.
Рис. .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). |
Блок подписи (запрос доставки)
Если предыдущиц документальный обмен 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:
| - блок платежного отклика, содержащий платежную расписку, и | |
| - блок отклика доставки, содержащий подробности о доставленных товарах или услугах. |
| 1. | Покупатель генерирует блок платежного запроса, в который, если требуется, вкладывается сообщение платежного протокола, и посылает его кассиру, снабжая опционно цифровой подписью |
| C a P | Платежный запрос. IotpMsg: блоки Trans Ref; подписи; платежного запроса |
| 2. | Кассир обрабатывает блок платежного запроса, проверяет опционную подпись и начинает обмен с покупателем в рамках платежного протокола (вкладывая эти сообщения в блоки платежного обмена) |
| C « P | Платежный обмен. IotpMsg: блоки Trans Ref; платежного обмена |
| 3. | Покупатель и кассир обмениваются блоками платежного обмена до тех пор пока платежный протокол не завершит свою работу. Кассир формирует компонент платежной расписки, помещает его в блок платежного отклика, опционно формирует компонент подписи, который укладывается в блок Signature, затем использует информацию из блока отклика предложения, чтобы сформировать блок отклика отклика доставки и посылает его покупателю. |
| C ? P | Отклики платежа и доставки. IotpMsg: блоки Trans Ref; подписи; платежного отклика; отклика доставки |
| 4. | Покупатель проверяет блоки платежного отклика и отклика доставки. Опционно он может вести запись всех транзакций. Здесь покупатель может остановиться или сформировать очередное сообщение и послать его соотвествующе торговой роли. |
/p> Рис. .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.
Рис. .24. Базовая транзакция аутентификации
Пример, использующий базовую транзакцию аутентификации, включает в себя следующие процедуры:
когда имеет место базовая транзакция аутентификации на ранней фазе сессии, тогда, например финансовая организация может:
как средство предоставления продавцу компонента Organisation, который содержит информацию о покупателе и торговой роли DelivTo;
предоставление возможности аутентифицировать кассира до начала процедуры платежа.
9.1.7. Базовая транзакция депозита
Базовая транзакция депозита поддерживает операции по размещению депозита электронных средств в финансовой орнганизации.
Финансовая организация в этой операции выполняет роль продавца (депозита электронных средств), который предлагает эту услугу за определенное вознаграждение, которое может поступить, например, с некоторого счета клиента в другом банке. Базовая транзакция депозита включает в себя следующие документальные обмены:
опционный документальный обмен аутентификации (смотри раздел 9.1.1);
документальный обмен предложения (смотри раздел 9.1.2) и
документальный обмен платежа (смотри раздел 9.1.3).
Способ, с помощью которого эти документальные обмены могут взаимодействовать, показан на рис. .25.
Рис. .25. Базовая транзакция депозита
Смотри раздел 9.1.12, чтобы определить какие комбинации документальных обменов применимы к конкретным транзакциям.
Заметим, что:
Продавец (финансовая организация) может принять депозит в виде различных видов электронных платежей. Но покупатель, который собирается разместить депозит, обячно знает, каким видом электронного платежа он намерен воспользоваться, по этой причине все многообразие электронных платежей в каждом конкретном случае сводится к одной разновидности. Однако могут быть несколько протоколов, которые могут использоваться с одним и тем же видом электронного платежа. В этом случае предложение, зависимое от вида платежа, може подойти для согласования используемого протокола.
Продавец (финансовая организация) может использовать результаты аутентификации не только для идентификации покупателя, но и счета, на котором следует разместить депозит. Если не удается идентифицировать один счет, используются другие средства. Например:
Базовая IOTP-транзакция депозита без аутентификации может быть использована:
9.1.8. Базовая транзакция покупки
Базовая транзакция покупки поддерживает покупку товаров или услуг с применением любых платежных методов. Она включает в себя следующие документальные обмены:
опционный документальный обмен аутентификации (смотри раздел 9.1.1)
документальный обмен предложения (смотри раздел 9.1.2)
или:
| - документальный обмен платежа ge (смотри раздел 9.1.3), за которым следует | |
| - документальный обмен доставки (смотри раздел 9.1.4) |
комбинированный документальный обменплатежа и доставки (смотри раздел 9.1.5).
Способы, какими эти документальные обмена могут комбинироваться показаны на рис. .26.
Рис. .26. Базовая транзакция покупки
Чтобы определить, какие комбинации документальных обменов встречаются в каждой из транзакций смотри раздел 9.1.12.
9.1.9. Базовая транзакция возврата денег
Процесс возврата денег обычно состоит из:
запроса возврата, направленного покупателем продавцу, и имеющего целью продемонстрировать:
Продавец соглашается (или нет) вернуть деньги. Это может включать некоторые переговоры между покупателем и продавцом, и если продавец согласен,
выполняется возврат денег продавцом покупателю.
Базовая транзакция возврата денег поддерживает субнабор возможностей перчисленных выше, в частности поддерживает:
отдельную аутентификацию покупателя, где используется базовая транзакция аутентификации (смотри раздел 9.1.6)
возвратный платеж продавца покупателю с помощью следующих двух торговых обменов:
| - опционный документальный обмен аутентификации (смотри раздел 9.1.1) | |
| - документальный обмен предложения (смотри раздел 9.1.2) и | |
| - документальный обмен платежа (смотри раздел 9.1.3). |
Рис. .27. Базовая транзакция возврата денег
Базовая транзакция возврата денег без документального обмена аутентификации может использоваться:
когда аутентификация покупателя осуществлена как-то иначе, например, покупатель, чтобы идентифицировать себя ввел представленный ему ранее код. Код может может быть записан на WEB-странице или прислан по электронной почте.
когда предыдущая транзакция, например базовая аутентификация, идентифицировала покупателя, при этом используется безопасный канал гарантирует корректность предыдущей аутентификации.
когда аутентификация покупателя осуществлена кассиром в рамках реализации платежного алгоритма.
9.1.10. Базовая транзакция отзыва платежа
Базовая транзакция отзыва поддерживает возврат электронных средств из финансовой организации.
Финансовая организация в рамках технологии IOTP имеет в этой транзакции, роль Продавца – за выполнение этой операции она может получить определенную оплату. Базовая транзакция отмены сделки включает в себя следующие документальные обмены:
опционный документальный обмен аутентификации (смотри раздел 9.1.1)
документальный обмен предложения (смотри раздел 9.1.2) и
документальный обмен платежа (смотри раздел 9.1.3).
Способы, какими эти документальные обмены могут комбинироваться показаны на рис. .28.
Рис. .28. Базовая транзакция отзыва сделки
Заметим, что:
Продавец (финансовая организация) может предложить реализацию возврата средств различными видами электронных платежей. Однако может быть несколько различных протоколов для каждого из видов электронных платежей.
Продавец ( финансовая организация) может использовать результаты аутентификации для того, чтобы идентифицировать не только покупателя, но счета, куда надлежит перевести возвращаемые средства. Если не удается идентифицировать один счет, используются другие средства. Например:
базовая транзакция отзыва может использоваться без аутентификации:
9.1.11. Базовая транзакция обмена ценностями
Базовая транзакция обмена ценностями использует документальный обмен платежа, чтобы поддержать обмен ценностями в одной валюте с помощью одного метода оплаты и с привлечением той же или (обычно) другой валюты с помощью того же или иного платежного метода (встречный платеж). Примеры реализации такой процедуры включают в себя:
Перенос электронных средств на кредитную карту. Например, первый платеж может быть "dollar SET Payment", использующий кредитную карту, а второй платеж использует кредитную карту Visa Cash и осуществляет электронный перевод в долларах.
Платежный обмен с заграничным субъектом посредством идентичных платежных методов. Например, один платеж может заключаться в снятии средств со счета в английских фунтах методом Mondex, а второй – предполагает внесение на счет денег в евро с помощью того же метода Mondex.
Платежный обмен с заграничным субъектом посредством различных платежных методов. Например, один платеж может осуществляться по протоколу SET в канадских долларах, а второй - методом GeldKarte в немецких марках.
Базовый обмен ценностями использует следующие документальные обмены:
опционный документальный обмен аутентификации (смотри раздел 9.1.1);
документальный обмен предложения (смотри раздел 9.1.2), который определяет детали того, какие суммы и валюты подлежат обмену и
два документальных обмена платежа (смотри раздел 9.1.3), которые осуществляют два реализуемые платежа.
Способы, которыми эти документальные обмены комбинируются друг с другом изображены на рис. .29.
Рис. .29. Базовая транзакция обмена ценностями
Базовая транзакция обмена ценностями осуществляется в двух вариантах:
Обмен ценностями, зависящий от вида платежа. Где содержимое предложения, например курс по которому одна форма ценности обменивается на вторую, зависит от вида платежа и протокола, выбранного клиентом и
Обмен ценностями, независящий от вида платежа. Где содержимое предложения, не зависит от вида платежа и протокола, выбранного клиентом.
В выше приведенном примере фигурирует роль продавца, хотя организацией, выполняющей обмен ценностями может быть банк или какая-то другая финансовая организация. Это потому, что банк выполняет здесь роль продавца, направляя покупателю предложение, которое он может принять или отвергнуть.
Блоки TPO и отклика Offer могут быть объединены в одном сообщении, только если содержимое блока отклика Offer не изменяется в результате выбора вида платежа и платежного протокола для обмена ценностями.
Использование подписей, чтобы гарантировать целостность обмена ценностями проиллюстрирована на диаграмме рис. .30.
Рис. .30. Подписи при обмене ценностями
9.1.12. Допустимые комбинации документальных обменов
Диаграмма на рис. .31. иллюстрирует информационные условия в различных IOTP-сообщениях, которые могут быть использованы покупателем, чтобы определить допустима или нет конкретная комбинация документальных обменов.
Рис. .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) |
|
e) Транзакция IOTP не включает в себя документальный обмен аутентификации (Замечание 2) |
|
3) Если блок отклина предложения присутствует в каком-либо сообщении IOTP, тогда:
Ниже представлена таблица типов транзакций, которые могут удовлетворять условиям перечисленным выше.
Замечание |
Корректность транзакции IOTP |
| 1. | Любая транзакция платежа и аутентификации |
| 2. | Любая транзакция платежа и аутентификации за исключением базовой аутентификации |
| 3. | Транзакция базовой аутентификации или базовой покупки, возврата денег, депозита, отзыва или обмена ценностями с не прошедшей аутентификацией |
| 4. | Толко базовая трканзакция покупки |
| 5. | Базовая транзация покупки, возврата денег, депозита и отзыва |
| 6. | Только базовый обмен ценностями |
9.1.13. Комбинирование аутентификации с другими транзакциями
Имеется возможность запустить независимую транзакцию аутентификации в любой момент времени, даже в параллель с другой транзакцией IOTP. Обычно она используется:
Покупателем, чтобы аутентифицировать продавца, кассира или агента доставки или
Кассиром или агентом доставки, чтобы аутентифицировать покупателя.
В общих чертах базовый процесс состоит из:
торговая роль, которая решает выполнить аутентификацию другой торговой роли, откладывает выполнение текущей транзакции;
выполняется не связанная ни с чем аутентификация. Это может быть опцией разработчика, подключенной к исходной транзакции с помощью компонента RelatedTo (смотри раздел 3.3.3) в блоке ссылок транзакции;
если транзакция аутентификации успешна essful, осходная транзакция возобновляется;
если аутентификация не прошла, тогда исходная аутентификация аннулируется.
Покупатель, например, может:
аутентифицировать кассира для платежа в период между получением отклика Offer от продавца и до посылки платежного запроса кассиру;
аутентифицировать агента доставки между получением платежного отклика от кассира и до отправки запроса доставки.
Кассир может аутентифицировать покупателя после получения платежного запроса и до посылки следующего сообщения, относящегося к платежу. агент доставки может аутентифицировать покупателя после получения запроса доставки и до посылки отклика доставки.
Некоторые платежные методы могут выполнять аутентификацию в ходе платежного обмена. В этом случае информация, необходимая для выполнения аутентификации будет включаться в компоненты платежной схемы.
В этом примере приложение IOTP не будет уверено, что аутентификация состоялась, так как компоненты платежной схемы, которые содержат аутентификационную информацию, не отличимы о других компонентов платежной схемы.
9.2. Инфраструктурные транзакции
Инфраструктурные транзакции разработаны, для поддержки запросов, прошла ли транзакция успешно или работает ли корректно некоторая торговая роль. Существует два типа таких транзакций:
транзакция запроса состояния транзакции, которая предоставляет информацию о статусе существующей или уже завершившейся транзакции;
транзакция Ping, которая позволяет одному приложению определить, работает ли соответствующее приложение другой торговой роли и проверить, могут ли обрабатываться подписи.
9.2.1. Базовая транзакция запроса состояния транзакции IOTP
Базовая транзакция запроса состояния предоставляет информацию о состоянии существующей или завершившейся транзакции IOTP. Базовая транзакция запроса состояния использует следующие торговые блоки:
торговый блок информационного запроса (смотри раздел 8.12),
торговый блок информационного отклика (смотри раздел 8.13)
опционный блок подписи (смотри раздел 8.16).
Запросы состояния транзакции IOTP могут производиться по разным причинам. Например:
чтобы помочь возобновить прерванную транзакцию и определить текущее состояние одной из других торговых ролей,
определить продавцу, завершен ли платеж, доставка и т.д.. Например, покупатель может объявить, что платеж произведен, но нет платежной расписки, подтверждающей это утверждение. Если продавец делает запрос кассиру, то он может определить, произведена или нет соответствующая проплата.
Запросы о базовых транзакциях IOTP Ping (смотри раздел 9.2.2) игнорируются.
Одна торговая роль может послать запрос любой другой торговой роли в любое время. Программа, которая поддерживает торговую роль покупателя IOTP может не делать:
не подписать цифровым образом отклик, если это запрашивается, при условии, что она не способна сделать это, или
совсем не реагировать на информационный запрос, так как она может быть в нерабочем состоянии или считать запрос неправомочным из-за того, что он, например, не подписан.
Базовыми требованиями являются:
Покупатель должен послать блок статусного запроса торговой роли только после следующих событий:
другие торговые роли должны послать блок информационного запроса состояния транзакции покупателю только после получения сообщения от покупателя и до отправки окончательного отклика покупателю ;
не существует ограничений на посылку информационных запросов для любых других торговых ролей помимо покупателя.
Ошибки в запросах состояния транзакции могут быть отнесены к следующим трем классам:
Рабочие ошибки (смотри раздел 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. | Первая торговая роль проверяет блок информационного отклика и опционную подпись, выполняет необходимые действия и останавливается. Это может включать отображение статусной информации конечному пользователю. |
/p> Рис. .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 и выполняет необходимые действия, если это требуется |
Верификация того, что подписи могут обрабатываться, осуществляется отправителем блока запроса 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, если они нужны.
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 |
10.3. Примеры логотипа для сетевой позиции
Если логотип сетевой позиции равен "ftp://logos.xzpay.com", тогда:
"ftp://logos.xzpay.com/medium.gif" извлечет логотип среднего размера с 256 цветами
"http://logos.xzpay.com/small4.gif" извлечет логотип малого размера с 16 цветами
Организации, которые делают логотип доступными для работы с IOTP должны всегда допускать размеры "small" и "medium" и использовать формат "gif".
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, и т.д..
поощрительные виды платежа (смотри ниже). Сюда входят:
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%, это означает, что покупатель в действительности платит меньше,
от эмитента платежного средства (карты), когда платеж появляется в ведомости. Например, процент за каждую операцию может быть понижен при частом использовании, основываясь на суммарой величине платежей с использованием данного платежного инструмента.
Заметим, что:
первый пример (получение выгоды в момент покупки), требует чтобы:
второй (получение выгоды от эмитента платежного средства) – не требует, чтобы отклик 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 и предварительно загруженных в приложение покупателя,
Используется некоторая информация, содержащаяся в программе, или другие данные, связанные с платежным инструментом. Это может быть:
покупатель устанавливает вручную связь между льготным видом платежа из списка, предложенного продавцом, и определенным платежным инструментом. Делается это при первом использовании льготного вида платежа. Приложение IOTP запоминает код льготного платежа для использования при будущих покупках.
11.1.5.3. Рекомендации для Id видов платежа в программе покупателя
Новые Id видов платежа выдаются в соответствии с процедурой, заданной IANA (смотри раздел 12).
Рекомендуется, чтобы разработчики приложений IOTP покупателя (напр., платежных программ) обеспечивали предварительную загрузку текущего набора идентификаторов вида платежа и предлагали средства пополнения этого списка.
11.2. Примеры видов платежа
Данный пример содержит три образца XML для компонента списка видов платежа:
вариант с просой кредитной карточкой;
список видов платежей, базирующихся на кредитной карте, включая льготные виды платежа, и
список видов платежа, базирующийся на комплексных электронных деньгах.
11.2.1. Простой пример, базирующийся на кредитной карте
Этот простой пример включает в себя:
только основные виды платежей с помощью кредитной карты;
одну цену и одну валюту;
одного Кассира и
один платежный протокол.
<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase book including s&h'
PayDirection='Debit' >
<Brand ID ='M1.30' BrandId='MasterCard' BrandName='MasterCard Credit'
BrandLogoNetLocn='ftp://otplogos.mastercard.com/mastercardcredit'
ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M.31' BrandId='Visa' BrandName='Visa Credit'
BrandLogoNetLocn='ftp://otplogos.visa.com/visacredit' ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M1.32' BrandId='AmericanExpress' BrandName='American Express'
BrandLogoNetLocn='ftp://otplogos.amex.com' ProtocolAmountRefs ='M1.33' >
</Brand >
<ProtocolAmount ID ='M1.33' PayProtocolRef='M1.35' CurrencyAmountRefs='M1.34'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.34' Amount='10.95' CurrCode='USD'/>
<PayProtocol ID ='M1.35' ProtocolId='SCCD1.0' ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
</PayProtocol>
</BrandList>
11.2.2. Список платежей с помощью кредитной карты, включая льготные платежи
Пример списка видов платежей с помощью кредитной карты представлен ниже. Он включает в себя:
два обычных вида платежа через кредитную карту и два льготных вида платежа.
два платежных протокола:
| - SET (Secure Electronic Transactions) смотри [SET] и | |
| - SCCD (Secure Channel Credit Debit) смотри [SCCD]. |
<Brand ID ='M1.3' BrandId='MasterCard' BrandName='MasterCard Credit'
BrandLogoNetLocn='ftp://otplogos.mastercard.com' ProtocolAmountRefs='M1.7 M1.8'>
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:'>
</ProtocolBrand>
</Brand>
<Brand ID ='M1.4' BrandId='Visa' BrandName='Visa Credit'
BrandLogoNetLocn='ftp://otplogos.visa.com' ProtocolAmountRefs='M1.7 M1.8'>
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='Visa:'>
</ProtocolBrand>
</Brand>
<Brand ID ='M1.5' BrandId='BritishAirwaysMC' BrandName='British Airways MasterCard'
BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk'
BrandNarrative='Double air miles with British Airways MasterCard'
ProtocolAmountRefs ='M1.7 M1.8' >
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:BA'>
</ProtocolBrand>
</Brand >
<Brand ID ='M1.6' BrandId='Walmart' BrandName='Walmart Store Card'
BrandLogoNetLocn='ftp://otplogos.walmart.com'
BrandNarrative='5% off with your Walmart Card on purchases over $150'
ProtocolAmountRefs='M1.8'>
</Brand>
<ProtocolAmount ID ='M1.7' PayProtocolRef='M1.10' CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<ProtocolAmount ID ='M1.8' PayProtocolRef='M1.11' CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<CurrencyAmount ID ='M1.9' Amount='157.53' CurrCode='USD'/>
<PayProtocol ID ='M1.10' ProtocolId='SET1.0'
ProtocolName='Secure Electronic Transaction Version 1.0'
PayReqNetLocn='http://www.example.com/etill/set1' >
<PackagedContent Transform="BASE64">
8ueu26e482hd82he82
</PackagedContent>
</PayProtocol>
<PayProtocol ID ='M1.11' ProtocolId='SCCD1.0'
ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
<PackagedContent Transform="BASE64">
82hd82he8226e48ueu
</PackagedContent>
</PayProtocol>
</BrandList>
11.2.3. Пример выбора вида платежа
Для оплаты через ' British Airways' MasterCard для выше приведенного варианта и платежного протокола SET список вида платежа будет иметь вид:
<BrandSelection ID='C1.2' BrandListRef='M1.3' BrandRef='M1.5' ProtocolAmountRef='M1.7'
CurrencyAmountRef='M1.9' >
</BrandSelection>
11.2.4. Список видов платежа, базирующихся на комплексных электронных деньгах
Ниже представлен достаточно сложный пример, который включает в себя:
платежи, использующие Mondex, GeldKarte, CyberCash или DigiCash;
в валютах, в список которых входят доллары США, британские фунты, итальянские лиры, немецкие марки и канадские доллары;
скидку на цену, если платеж выпонен через Mondex, используя британские фунты или американские доллары и
более одного Кассира для случаев использования Mondex или CyberCash;
поддержка более чем одной версии CyberCash для платежного протокола CyberCoin.
<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Company report on XYZ Co'
PayDirection='Debit'>
<Brand ID ='M1.13' BrandId='Mondex' BrandName='Mondex Electronic Cash'
BrandLogoNetLocn='ftp://otplogos.mondex.com' ProtocolAmountRefs='M1.17 M1.18'>
</Brand>
<Brand ID ='M1.14' BrandId='GeldKarte' BrandName='GeldKarte Electronic Cash'
BrandLogoNetLocn='ftp://otplogos.geldkarte.co.de' ProtocolAmountRefs='M1.19'>
</Brand>
<Brand ID ='M1.15' BrandId='CyberCoin' BrandName='CyberCoin Eletronic Cash'
BrandLogoNetLocn='http://otplogos.cybercash.com' ProtocolAmountRefs ='M1.20'>
</Brand >
<Brand ID ='M1.16' BrandId='DigiCash' BrandName='DigiCash Electronic Cash'
BrandLogoNetLocn='http://otplogos.digicash.com'
BrandNarrative='5% off with your Walmart Card on purchases over $150'
ProtocolAmountRefs='M1.22'>
</Brand>
<ProtocolAmount ID ='M1.17' PayProtocolRef='M1.31'
CurrencyAmountRefs='M1.25 M1.29'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.18' PayProtocolRef='M1.32'
CurrencyAmountRefs='M1.26 M1.27 M1.28 M1.30'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.19' PayProtocolRef='M1.35' CurrencyAmountRefs='M1.28'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.20' PayProtocolRef='M1.34 M1.33'
CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.21' PayProtocolRef='M1.36'
CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.23' Amount='20.00' CurrCode='USD'/>
<CurrencyAmount ID ='M1.24' Amount='12.00' CurrCode='GBP'/>
<CurrencyAmount ID ='M1.25' Amount='19.50' CurrCode='USD'/>
<CurrencyAmount ID ='M1.26' Amount='11.75' CurrCode='GBP'/>
<CurrencyAmount ID ='M1.27' Amount='36.00' CurrCode='DEM'/>
<CurrencyAmount ID ='M1.28' Amount='100.00' CurrCode='FFR'/>
<CurrencyAmount ID ='M1.29' Amount='22.00' CurrCode='CAD'/>
<CurrencyAmount ID ='M1.30' Amount='15000' CurrCode='ITL'/>
<PayProtocol ID ='M1.31' ProtocolId='MXv1.0'
ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankus.com/etill/mx' >
</PayProtocol>
<PayProtocol ID ='M1.32' ProtocolId='MXv1.0'
ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankuk.com/vserver' >
</PayProtocol>
<PayProtocol ID ='M1.33' ProtocolId='Ccashv1.0' ProtocolName='CyberCoin Version 1.0'
PayReqNetLocn='http://www.cybercash.com/ccoin' >
</PayProtocol>
<PayProtocol ID ='M1.34' ProtocolId='CCashv2.0' ProtocolName='CyberCoin Version 2.0'
PayReqNetLocn='http://www.cybercash.com/ccoin' >
</PayProtocol>
<PayProtocol ID ='M1.35' ProtocolId='GKv1.0' ProtocolName='GeldKarte Version 1.0'
PayReqNetLocn='http://www.example.com/pgway'>
</PayProtocol>
<PayProtocol ID ='M1.36' ProtocolId='DCashv1.0'
ProtocolName='DigiCash Protocol Version 1.0'
PayReqNetLocn='http://www.example.com/digicash' >
</PayProtocol>
</BrandList>
12. Соображения IANA
12.1. Коды контролируемые IANA
Для того чтобы гарантировать совместимость, коды, используемые IOTP, нужно поддерживать в контролируемой среде так, что их значения и использование были строго определены, а дублирование кодов должно быть исключено. IANA представляет механизм решения этой проблемы, как это описано в RFC 2434.
Типы элементов и имена атрибутов, к которым эта процедура применяется, приведены ниже в таблице вместе с исходными величинами, разрешенными для этих атрибутов.
Заметим, что:
торговый подписной лист IETF имеет адрес ietf-trade@elistx.com
"Специальные эксперты (Designated Experts)" (смотри [IANA]) назначаются IESG.
| Тип элемента/Имя атрибута | Значения атрибутов |
| Алгоритм/Имя | "sha1" – указывает, что будет использована аутентификация [SHA1] |
| (Когда алгоритм является производным от компонента AuthReq) | "Подпись" – указывает, что аутентификация включает в себя генерацию цифровой подписи. |
| "Pay:ppp", где "ppp" может быть установлено равным любому допустимому значению для "iotpbrand" (смотри ниже) |
Элемент 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" |
/p> Новые значения BrandId должны быть опубликованы через торговый подписной лист IETF и, если в течение трех недель не поступает возражений, они присваиваются в порядке поступления.
| Валютная сумма/CurrCode | Коды валюты зависят от CurrCodeType (смотри ниже). |
Если CurrCodeType = "IOTP", тогда новые значения должны быть опубликованы через торговый подписной лист IETF и, если в течение трех недель не поступает возражений, они присваиваются в порядке поступления.
Код типа валюты IOTP, сконструирован так, чтобы позволять поддержку "новых" псевдовалют, таких как loyalty или frequent flyer points. На момент написания этого документа ни один из таких кодов не был лпределен.
Тип элемента/Имя атрибута |
Значения атрибута |
| Валютная сумма/CurrCodeType |
"ISO4217A" "IOTP" |
| DeliveryData/DelivMethod |
"Post" "Web" "Email" |
| PackagedContent/Content |
"PCDATA" "MIME" "MIME:mimetype" (где mimetype должен быть тем же, что и в content-type, как это определено в [MIME]) "XML" |
В противном случае, новые значения атрибута Content выделяются после публикования через подписной лист IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как используется новый атрибут в элементе Packaged Content.
| RelatedTo/RelationshipType |
"IotpTransaction" "Reference" |
/p> Новые значения атрибута RelationshipType выделяются после публикования через подписной лист табочей группы IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как осуществляется метод доставки.
Тип элемента/Имя атрибута |
Значения атрибута |
| Status/StatusType | Предложение Платеж Доставка Аутентификация Не идентифицировано Новые значения атрибута Status Type выделяются после: oпубликации в Торговой Рабочей Группе IETF, документа RFC, описывающего торговый обмен, торговые роли и соответствующие компоненты, которые относятся к Status и oрассмотрения документа в торговом почтовом листе IETF и экспертами. |
| TradingRole/TradingRole |
"Consumer" "Merchant" "PaymentHandler" "DeliveryHandler" "DelivTo" oрассмотрения документа в торговом почтовом листе IETF и экспертами. |
| Тип элемента/Имя атрибута | Значения атрибута |
| TransId/IotpTransType |
"BaselineAuthentication" "BaselineDeposit" "BaselineRefund" "BaselineWithdrawal" "BaselineValueExchange" "BaselineInquiry" "BaselinePing" Новые значения атрибута IotpTransType выделяются после: oпубликации через почтовый список IETF, в виде документа RFC, описывающего новую транзакцию IOTP и oрассмотрения документа в почтовом списке торговой рабочей группы IETF и экспертами. |
|
Attribute/Content (смотри компонент Signature) |
"OfferResponse" "PaymentResponse" "DeliveryResponse" "AuthenticationRequest" "AuthenticationResponse" "PingRequest" "PingResponse" Новые значения кода, которые описывают тип подписи выделяются после: oпубликации в Торговой Рабочей Группе IETF документа RFC, описывающего торговый обмен, где используются подписи и oрассмотрения документа в торговом почтовом листе IETF и экспертами. |
/p> Документ, описывающий новые значения типа подписи, может быть объединен с документами, описывающими новые типы Status и торговые роли (смотри выше).
12.2. Коды, неконтролируемые IANA
Помимо формального выбора и регистрации кодов, как это описано выше, для разработчиков существует необходимость экспериментировать с новыми кодами IOTP. По этой причине могут использоваться "коды определенные пользователем", что не требует регистрациив IANA. Определение кода, задаваемого пользователем, выглядит следующим образом:
user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*
| NameChar | NameChar имеет то же определение, что и [XML] определение NameChar. |
13. Определения типов данных протокола IOTP
Этот раздел содержит XML DTD для IOTP.
<!--
******************************************************
* *
* INTERNET OPEN TRADING PROTOCOL VERSION 1.0 DTD *
* Имя файла: ietf.org/rfc/rfc2801.dtd *
* *
* Отличие от версии 07 (iotp-v1.0-protocol-07.dtd) *
* - никаких изменений *
* *
* Copyright Internet Engineering Task Force 1998-2000*
* *
******************************************************
******************************
* Определение сообщения IOTP *
******************************
-->
<!ELEMENT IotpMessage ( TransRefBlk, IotpSignatures?, ErrorBlk?,
( AuthReqBlk | AuthRespBlk | AuthStatusBlk | CancelBlk | DeliveryReqBlk |
DeliveryRespBlk | InquiryReqBlk | InquiryRespBlk | OfferRespBlk | PayExchBlk |
PayReqBlk | PayRespBlk | PingReqBlk | PingRespBlk | TpoBlk | TpoSelectionBlk
)* ) >
<!ATTLIST IotpMessage xmlns CDATA 'iotp:ietf.org/iotp-v1.0' >
<!--
***************************************
* Определение блока ссылок транзакции *
*************************************** -->
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*)>
<!ATTLIST TransRefBlk ID ID #REQUIRED>
<!ELEMENT TransId EMPTY>
<!ATTLIST TransId ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0'IotpTransId CDATA #REQUIRED
IotpTransType CDATA #REQUIREDTransTimeStamp CDATA #REQUIRED>
<!ELEMENT MsgId EMPTY>
<!ATTLIST MsgId ID ID #REQUIRED
SenderTradingRoleRef NMTOKEN #IMPLIED
<!ELEMENT RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo ID ID #REQUIRED
| xml:lang NMTOKEN #REQUIRED | RelationshipType NMTOKEN #REQUIRED |
| Relation CDATA #REQUIRED | RelnKeyWords NMTOKENS #IMPLIED> |
**********************************
* Общий элемент Packaged Content *
********************************** -->
<!ELEMENT PackagedContent (#PCDATA)>
<!ATTLIST PackagedContent Name CDATA #IMPLIED
<!--
***********************
* Торговые компоненты *
*********************** -->
<!-- PROTOCOL OPTIONS COMPONENT -->
<!ELEMENT ProtocolOptions EMPTY >
<!ATTLIST ProtocolOptions ID ID #REQUIRED
SuccessNetLocn CDATA #REQUIRED>
<!-- AUTHENTICATION DATA COMPONENT -->
<!ELEMENT AuthReq (Algorithm, PackagedContent*)>
<!ATTLIST AuthReq ID ID #REQUIRED
AuthenticationId CDATA #REQUIREDContentSoftwareId CDATA #IMPLIED>
<!-- AUTHENTICATION RESPONSE COMPONENT -->
<!ELEMENT AuthResp (PackagedContent*) >
<!ATTLIST AuthResp ID ID #REQUIRED
AuthenticationId CDATA #REQUIREDSelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!-- TRADING ROLE INFO REQUEST COMPONENT -->
<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq ID ID #REQUIRED
TradingRoleList NMTOKENS #REQUIRED>
<!-- ORDER COMPONENT -->
<!ELEMENT Order (PackagedContent*)>
><! ATTLIST Order ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!-- ORGANISATION COMPONENT -->
<!ELEMENT Org (TradingRole+, ContactInfo?, PersonName?, PostalAddress?)>
<!ATTLIST Org ID ID #REQUIRED
LogoNetLocn CDATA #IMPLIED>
<!ELEMENT TradingRole EMPTY>
><!ATTLIST TradingRole ID ID#REQUIRED
ErrorLogNetLocn CDATA #IMPLIED>
<!ELEMENT ContactInfo EMPTY>
<!ATTLIST ContactInfo xml:lang NMTOKEN #IMPLIED
<!ELEMENT PersonName EMPTY >
<!ATTLIST PersonName xml:lang NMTOKEN #IMPLIED
<!ELEMENT PostalAddress EMPTY>
<!ATTLIST PostalAddress xml:lang NMTOKEN #IMPLIED
LegalLocation (True | False) 'False' >
<!-- BRAND LIST COMPONENT -->
<!ELEMENT BrandList (Brand+, ProtocolAmount+, CurrencyAmount+, PayProtocol+)>
(Debit | Credit) #REQUIRE>
<!ELEMENT Brand (ProtocolBrand*, PackagedContent*)>
<!ATTLIST Brand ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT ProtocolBrand (PackagedContent*) >
<! ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #REQUIRED>
<!ELEMENT ProtocolAmount (PackagedContent*) >
ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT CurrencyAmount EMPTY >
CurrCode CDATA #REQUIRED>
<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- BRAND SELECTION COMPONENT -->
<!ELEMENT BrandSelection (BrandSelBrandInfo?,
ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED>
<!ELEMENT BrandSelBrandInfo (PackagedContent+)>
<!ATTLIST BrandSelBrandInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+)>
<!ATTLIST BrandSelProtocolAmountInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+)>
<!ATTLIST BrandSelCurrencyAmountInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT COMPONENT -->
<!ELEMENT Payment EMPTY>
StartAfterRefs NMTOKENS #IMPLIED>
<!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent+) >
<!-- PAYMENT RECEIPT COMPONENT -->
<!ELEMENT PayReceipt (PackagedContent*) >
<!-- PAYMENT NOTE COMPONENT -->
<!ELEMENT PaymentNote (PackagedContent+)>
<!ATTLIST PaymentNote ID ID #REQUIREDContentSoftwareId CDATA #IMPLIED>
<!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
| <!ATTLIST Delivery ID | ID #REQUIRED |
<!ELEMENT DeliveryData (PackagedContent*) >
ContentSoftwareId CDATA #IMPLIED>
<!-- CONSUMER DELIVERY DATA COMPONENT -->
<!ELEMENT ConsumerDeliveryData EMPTY>
<!ATTLIST ConsumerDeliveryData ID ID #REQUIRED
ConsumerDeliveryId CDATA #REQUIRED>
<!-- DELIVERY NOTE COMPONENT -->
<!ELEMENT DeliveryNote (PackagedContent+)>
ContentSoftwareId CDATA #IMPLIED >
<!-- STATUS COMPONENT -->
<!ELEMENT Status EMPTY>
CompletionCode NMTOKEN #IMPLIED
<!-- TRADING ROLE DATA COMPONENT -->
<!ELEMENT TradingRoleData (PackagedContent+)>
<!ATTLIST TradingRoleData ID ID #REQUIRED
<!ELEMENT InquiryType EMPTY>
ProcessReference CDATA #IMPLIED >
<!-- ERROR COMPONENT -->
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*)>
<!ELEMENT ErrorLocation EMPTY >
AttName NMTOKEN #IMPLIED>
<!--
**********************
* ТОРГОВЫЕ БЛОКИ *
********************** -->
<!-- TRADING PROTOCOL OPTIONS BLOCK -->
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* )>
<!ATTLIST TpoBlk ID ID #REQUIRED >
<!-- TPO SELECTION BLOCK -->
<!ELEMENT TpoSelectionBlk (BrandSelection+)>
<!ATTLIST TpoSelectionBlk ID ID #REQUIRED>
<!-- OFFER RESPONSE BLOCK -->
<!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*)>
<!ATTLIST OfferRespBlk ID ID #REQUIRED >
<!-- AUTHENTICATION REQUEST BLOCK -->
<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?)>
<!ATTLIST AuthReqBlk ID ID #REQUIRED>
<!-- AUTHENTICATION RESPONSE BLOCK -->
<!ELEMENT AuthRespBlk (AuthResp?, Org*)>
<!ATTLIST AuthRespBlk ID ID #REQUIRED>
<!-- AUTHENTICATION STATUS BLOCK -->
<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk ID ID #REQUIRED>
<!-- PAYMENT REQUEST BLOCK -->
<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*, TradingRoleData*)>
<! ATTLIST PayReqBlk ID ID #REQUIRED>
<!-- PAYMENT EXCHANGE BLOCK -->
<!ELEMENT PayExchBlk (PaySchemeData)>
<!ATTLIST PayExchBlk ID ID #REQUIRED>
<!-- PAYMENT RESPONSE BLOCK -->
<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
PaymentNote?, TradingRoleData*) >
<!ATTLIST PayRespBlk ID ID #REQUIRED>
<!-- DELIVERY REQUEST BLOCK -->
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
ConsumerDeliveryData?, TradingRoleData*) >
<!ATTLIST DeliveryReqBlk ID ID #REQUIRED>
<!-- DELIVERY RESPONSE BLOCK -->
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote)>
<!ATTLIST DeliveryRespBlk ID ID #REQUIRED>
<!-- INQUIRY REQUEST BLOCK -->
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? )>
<!ATTLIST InquiryReqBlk ID ID #REQUIRED >
<!-- INQUIRY RESPONSE BLOCK -->
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?)>
<!ATTLIST InquiryRespBlk ID ID #REQUIRED
LastReceivedIotpMsgRef NMTOKEN #IMPLIED
LastSentIotpMsgRef NMTOKEN #IMPLIED>
<!-- PING REQUEST BLOCK -->
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk ID ID #REQUIRED>
<!-- PING RESPONSE BLOCK -->
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk ID ID #REQUIRED
PingStatusCode (Ok | Busy | Down) #REQUIRED
BR/P>
xml:lang NMTOKEN #IMPLIEDPingStatusDesc CDATA #IMPLIED>
<!-- ERROR BLOCK -->
><!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*)>
<!ATTLIST ErrorBlk ID ID #REQUIRED>
<!-- CANCEL BLOCK -->
<!ELEMENT CancelBlk (Status)>
<!ATTLIST CancelBlk ID ID #REQUIRED>
<!--
*****************************
* Определение блока подписи *
***************************** -->
<!ELEMENT IotpSignatures (Signature+ ,Certificate*)>
<!ATTLIST IotpSignatures ID ID #IMPLIED>
<!--
*******************************************
* Определение компонента подписи IOTP *
******************************************* -->
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature ID ID #IMPLIED>
<!ELEMENT Manifest ( Algorithm+,
Digest+,
Attribute*,
OriginatorInfo,
RecipientInfo+ )>
<!ATTLIST Manifest LocatorHRefBase CDATA #IMPLIED>
<!ELEMENT Algorithm (Parameter*)>
<!ATTLIST Algorithm ID ID #REQUIRED
>type (digest|signature) #IMPLIEDname NMTOKEN #REQUIRED>
<!ELEMENT Digest (Locator, Value)>
<!ATTLIST Digest DigestAlgorithmRef IDREF #REQUIRED>
<!ELEMENT Attribute ( ANY ) >
<!ATTLIST Attribute type NMTOKEN #REQUIRED
>critical ( true | false ) #REQUIRED>
<!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo OriginatorRef NMTOKEN #IMPLIED>
<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #IMPLIEDSignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED>
<!ELEMENT KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier value CDATA #REQUIRED>
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter type CDATA #REQUIRED>
><!--
*******************************************
* Определение компонента сертификата IOTP *
******************************************* -->
<!ELEMENT Certificate ( IssuerAndSerialNumber, ( Value | Locator ) )>
<!ATTLIST Certificate ID ID #IMPLIEDtype NMTOKEN #REQUIRED>
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber issuer CDATA #REQUIRED number CDATA
#REQUIRED>
<!--
**************************************
* Определение компонента SHARED IOTP *
************************************** -->
<!ELEMENT Value ( #PCDATA )>
<!ATTLIST Value ID ID #IMPLIED encoding (base64|none) 'base64'>
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator xml:link CDATA #FIXED 'simple' href CDATA #REQUIRED>
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 |
/p>
15. Ссылки
| [Base64] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. |
| [DOM-HASH] | Maruyama, H., Tamura, K. and N. Uramoto, "Digest Values for DOM (DOMHASH)", RFC 2803, April 2000. |
| [DNS] | Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. |
| [DNS] | Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. |
| [DSA] | The Digital Signature Algorithm (DSA) published by the National Institute of Standards and Technology (NIST) in the Digital Signature Standard (DSS), which is a part of the US government's Capstone project. |
| [ECCDSA] | Elliptic Curve Cryptosystems Digital Signature Algorithm (ECCDSA). Elliptic curve cryptosystems are analogues of public-key cryptosystems such as RSA in which modular multiplication is replaced by the elliptic curve addition operation. See: V. S. Miller. Use of elliptic curves in cryptography. In Advances in Cryptology - Crypto '85, pages 417-426, Springer-Verlag, 1986. |
| [HMAC] | Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. |
| [HTML] | Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995. |
| [HTML] | Hyper Text Mark Up Language. The Hypertext Mark-up Language (HTML) is a simple mark-up language used to create hypertext documents that are platform independent. See the World Wide Web (W3C) consortium web site at: http://www.w3.org/MarkUp/ |
| [HTTP] | Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC-1945, May 1996. |
| [HTTP] | Fielding, R., Gettys, J., Mogul, J., Frystyk, T. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1.", RFC-2616, June 1999. |
| [IANA] | The Internet Assigned Numbers Authority. The organisation responsible for co-ordinating the names and numbers associated with the Internet. See http://www.iana.org/ |
| [ISO4217] | ISO 4217: Codes for the Representation of Currencies. Available from ANSI or ISO. |
| [IOTPDSIG] | Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC-2802, April 2000. |
| [MD5] | Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, April 1992. |
| [MIME] | Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. |
| [MIME] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC-2045, November 1996. |
| [MIME] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC-2046, November 1996. |
| [MIME] | Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text" RFC-2047, November 1996. |
| [MIME] | Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC-2048, November 1996. |
| [MIME] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples" RFC-2049, November 1996. |
| [OPS] | Open Profiling Standard. A proposed standard which provides a framework with built-in privacy safeguards for the trusted exchange of profile information between individuals and web sites. Being developed by Netscape and Microsoft amongst others. |
| [RFC1738] | Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC-1738, December 1994. |
| [RFC2434] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC-2434, October 1998. |
| [RSA] | RSA is a public-key cryptosystem for both encryption and authentication supported by RSA Data Security Inc. See: R. L. Rivest, A. Shamir, and L.M. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2): 120-126, February 1978. |
| [SCCD] | Secure Channel Credit Debit. A method of conducting a credit or debit card payment where unauthorised access to account information is prevented through use of secure channel transport mechanisms such as SSL/TLS. An IOTP supplement describing how SCCD works is under development. |
| [SET] | Secure Electronic Transaction Specification, Version 1.0, May 31, 1997. Supports credit and debit card payments using certificates at the Consumer and Merchant to help ensure authenticity. Download from: <http://www.setco.org>. |
| [SSL/TLS] | Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC-2246, January 1999. |
| [SHA1] | [FIPS-180-1]"Secure Hash Standard", National Institute of Standards and Technology, US Department Of Commerce, April 1995. Also known as: 59 Fed Reg. 35317 (1994). See http://www.itl.nist.gov/div897/pubs/fip180-1.htm |
| [UTC] | Universal Time Co-ordinated. A method of defining time absolutely relative to Greenwich Mean Time (GMT). Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" where the "+n" defines the number of hours from GMT. See ISO DIS8601. |
| [UTF16] | The Unicode Standard, Version 2.0. The Unicode Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 Proposed Draft Amendment 1 |
| [X.509] | ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, Including Draft Amendment 1: Certificate Extensions (Version 3 Certificate) |
| [XML | Recommendation for Namespaces in XML, World Wide Web Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC-xml-names" |
| [XML] | Extensible Mark Up Language. A W3C recommendation. See http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 version. |
Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"
11 Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"
Семенов Ю.А. (ГНЦ ИТЭФ)
(http://book.itep.ru)
Этот сервер официально зарегистрирован на Rambler лишь в марте 2002 года, но существует он уже с конца 1999 года. Отклики интересны, прежде всего, тем, что они написаны по инициативе отправителя. Я полагаю, что многие из читателей время от времени просматривают самые разные сайты в Интернет. Но вряд ли многие пишут на них отклики...
Я сознательно исключил переписку, возникавшую в связи с присланными запросами. Не все отклики попали в перечень (я получаю большой объем СПАМа и часто слишком поспешно уничтожаю сообщения от незнакомых лиц). Признаюсь, я не всегда отвечаю на приходящие письма, так как их число превышает 50 в день… География откликов довольно широка (Владивосток, Новосибирск, Иркутск, С-Петербург, Ижевск, Саратов, Ноябрьск, Луганск, Тихорецк, Киев, Эстония, США, Болгария и, конечно же, Москва). В основном они положительны (может быть отчасти потому, что авторы о чем-то просят J). Но был один явно отрицательный отклик, он также включен в перечень. Было несколько запросов относительно off-line версии сервера. Отвечая на них, скажу, что я планирую изготовить CD-версию сервера, но дело это хлопотное и экономически совершенно нерациональное. Обычно в такой версии нуждаются люди с плохим доступом к Интернет (как правило не москвичи), себестоимость такого CD около 2$, плюс цена пересылки, назначить цену, которая бы компенсировала трудозатраты я не могу, да и люди не смогут ее заплатить, а рассылать диски с убытком не позволяет моя зарплата.
Отклики размещены в хронологическом порядке, со временем надеюсь создать “нормальную” книгу посещений-отзывов.
From: Andrey Cherezov andrey@cherezov.koenig.su
To: semenov@ns.itep.ru
Subject: О ваших Книгах
Date: 2 августа 1998 г. 22:15
Добрый день!
Неужели Вы тот самый Ю.А.Семенов, который книгу о Форте написал?! J
Очень рад, что теперь можно с вами поговорить!
Всего наилучшего, Андрей Черезов http://www.enet.ru/win/cherezov/
Date: Sat, 27 Mar 1999 20:38:37
Уважаемый господин Cеменов!
Oглавление, перечисляющее разделы вашего сайта "Cети Интернет", просто потрясающее. Но по каким-то причинам Я не могу открыть большинство страниц. Если они (страницы :-) уже созданы, то хотелось бы, чтоб проблемы, связанные с этим (причинами :-( , поскорее были преодолены.
C уважением,
Bаш потенциальный постоянный посетитель
Aлександр <lommoff@yahoo.com>
Date: Mon, 6 Mar 2000 03:56:49
Восхищен и поражен Вашим сайтом Telecommunication technologies - телекоммуникационные технологии. Творческих успехов и всего хорошего.
Egor Kobylkin egork@iname.com http://i.am/egork
Date: Thu, 1 Jun 2000 13:47:11
Уважаемый Юрий Алексеевич!
С удовольствием прочитал в Интернет Вашу книгу "Сети Интернет..." Благодарю за бесплатное размещение этой очень полезной книги в сети. Пользуясь случаем, прошу оказать помощь в приобретении полного текста. Рекомендаций МСЭ-Т G.703 (Копия, оригинал или адрес в сети). Посоветуйте где это можно найти.
С уважением
Ведущий специалист ЗАО"АКОС" (Сотовая связь. г. Владивосток)
Сергей Гречуха
мой адрес: sgrechuha@akos.ru
Date: Wed, 14 Jun 2000 16:25:45
Добрый день, Юрий Алексеевич.
Я студент МФТИ ФРТК 4-й курс, пишу вам по поводу вашей книги Телекоммуникационные Технологии (http://book.itep.ru). В данный момент занимаюсь моделированием локальных сетей на языке GPSS/PC. В частности, моделирую Ethernet 802.3 коллизийный домен. Я нашел некоторые неоднозначности в разной литературе описывающие протокол CSMA/CD.
И хотел бы у вас утонить правильность моих рассуждений, так как при моделировании данной сети, у меня получается, что одна станция (по крайней мере из 3-х станций в сети) захватывает весь эфир и не дает возможность передавать другим. Как работает CSMA/CD, я понимаю так:
1. Станция все время прослушивает среду (шину). Если среда свободна (освободилась), то ждет interframe gap
(межкадровый интервал), равный 9,6 мкс (в это время все равно слушает среду). Если в течение этих 9,6 мкс никто не захватил шину, то начинает передавать (шаг 2.). Если кто-то захватил шину в течение этого времени, то возвращается к шагу 1.
2. При передачи, станция все время слушает среду. Если обнаруживает коллизию, то посылает сигнал коллизии 32 BT = 3.2 мкс. И вычисляет задержку по формуле (51,2*(RAND [0,(2^m-1)]), где m = min (к,10), а к - число коллизий, при передачи данного кадра. То есть, если к=1, то возможная задержка (0, 51.2) если к=2, то возможная задержка (0, 51.2, 102.4, 52428.8), и т.д. После ожидания вычисленной задержки, возвращается к шагу 1. Если к=16, станция отказывается отправлять кадры. (Кстати, у Вас задержка вычисляется по формуле (51,2*(RAND [0,(2^m)]))
3.Если коллизии не было, то завершает передачу. Устанавливает к = 0. Возвращается к шагу 1. Я моделирую насыщенный режим работы сегмента и почему-то одна станция захватывает весь эфир. Модель работает к предписано алгоритмом выше. Попробовал аналитически рассмотреть работу >CSMA/CD. Допустим все станции (3 штуки) захотели передавать в одно и тоже время, определив, что шина свободна. Обнаружится коллизия, все станции идут в задержку. прибавляя к 'К' единицу. Далее, кто первее освободился (если задержка 0, то сразу идет к шагу 1), тот начал передачу. Во время передачи этой станции освобождаются, другие станции из коллизийной задержки. Соответственно ждут, пока освободит шину передающая станция (шаг 1). Как только эта станция освобождает шину, она идет в шаг 1. (причем 'к' сбрасывает в нуль) на ровне с другими станциями. Ждут 96 ВТ = 9.6 мкс межкадрового времени, начинают передавать. Опять образуется коллизия. У первой станции 'к' будет равно единицы, а у других 'к'=2. Это говорит о том, что вероятность получить меньшую задержки у первой станции больше чем у других. (у меня так и происходит). станция с к=1 выбирает меньшую задержку, чем другие. Ждет и идет передавать. Далее все идет по циклу, у первой станции 'к' то обнуляется, то равно 1, у других станций 'к' растет, соответственно, вероятность получить большую задержку тоже растет. Я моделировал передачу кадров минимальной длины, что уж говорить о кадров максим. длины 1526КВ. Ситуация на мой взгляд еще больше усугубится. Юрий Алексеевич, подскажите, может быть я не правильно понял алгоритм? Он несколько отличается от Вашего (http://book.itep.ru/4/41/Eth_4111.htm), но мне кажется не принципиально.
Всего доброго, Рябенко Максим maxy@rt.mipt.ru
Date: Wed, 12 Jul 2000 16:45:27
Уважаемый Юрий Алексеевич
В своей книге "Сети Интернет. Архитектура и протоколы", Вы пишите о том, что Вы написали собственную программу для анализа сетевого трафика, и в частности эта программа анализирует содержимое MIB. Меня интересует такой вопрос: как в Вашей программе реализован поиск SNMP-агентов, и можно ли организовать его автоматически?
С уважением, Юрий Чашков. chashkov@mail.ru
Date: Fri, 4 Aug 2000 15:32:33
Здравствуйте.
В Вашей книге (http://book.itep.ru/7/Prog_72.htm)
читаю:
"...(см. также руководство по сетевому контроллеру 8390 и файл NE2.ASM из ссылки ftp.funet.fi)..." Не могли бы Вы уточнить, действительно ли существует описание 8390 в Интернете и как его выловить? (очень надо для отладки драйвера под RTEMS)
Спасибо.
Sincerely, Dmitry Kargapolov, ICQ 54000305, dk@gentex.ru
Date: Tue, 15 Aug 2000 05:16:31
Доброго времени суток Юрий Алексеевич.
Попал на Ваш сайт, и был приятно удивлен количеству полезной информации. Но к сожалению, я не имею постоянной возможности работы в Интернете. И меня интересует, такая возможность, как получить Ваш сайт в виде архива. Для ЛИЧНОГО использования. По некоторым статьям я считаю, что мог бы несколько дополнить их. Но, к сожалению, по причине описанной выше не могу внимательно ознакомится с теми разделами, в которых у меня имеется богатый практический опыт. Рад буду, если Вы откликнитесь на мою просьбу. А также надеюсь на плодотворное сотрудничество.
Заранее спасибо.
С уважением Алексей Алексеевич. mailto:wwfnet@mail.ru
Date: Thu, 31 Aug 2000 12:49:28
Уважаемый Юрий Алексеевич!
Сердечно благодарю Вас за отклик на нашу просьбу. Надеюсь, что Вы сможете, что-нибудь придумать. Информацию о сфере нашей деятельности, заказчиках и др. Вы сможете посмотреть на нашем сайте. Очень горжусь, пусть телефонным, знакомством с Вами и надеюсь, что смогу быть Вам полезным. С Уважением и наилучшими пожеланиями, исполнительный директор НПФ Беркут
Кельганкин Олег
ook@bercut.spb.ru
www.bercut.ru
т/ф (812) 271-48-98
т/ф (812) 274-70-59
т/ф (812) 275-44-91
Россия, Санкт-Петербург, Моисеенко 43.
Date: Thu, 31 Aug 2000 13:48:14
Здравствуйте Юpий Алексеевич!
Ну для начала я представлюсь. Корнилов Игорь Геннадьевич, 25 лет. Работаю ставшим преподавателем на кафедре ВТ ИжГТУ (Ижевский гос. тех. университет). С прошлого года я читаю курсы по корпоративным сетям и Интернету. В подготовке к лекциям в прошлом году мне сильно помогала Ваша книга "Протоколы и ресурсы INTERNET". Позже я стал пользоваться сервером book.itep.ru. Замечательный, полезный сервер! Спасибо Вам огромное>! Но у нас есть одна проблема! Канал через который подключен к инету наш университет не отличается высокой скоростью и надежностью. :( А я бы хотел, чтоб ресурсами вашего сервера могли свободно пользоваться наши студенты. И в связи с этим вопрос: можно ли разместить зеркало вашего сервера на сервере нашей кафедры?
С уважением, Корнилов Игорь. eggog@vao.udmnet.ru
Date: Mon, 04 Sep 2000 10:59:47
Добpый день, Юpий Алексеевич
Зеркало уже почти готово! Скоро я его размещу на нашем сервере zuko.istu.udm.ru. У меня уже есть старая копия, которой я пользовался. Hо из миpа в настоящее время его видно не будет (проблемы с внешними каналами :((( Как только появится возможность доступа к нам из вне я Вам сообщу дополнительно. И вот тут еще. Меня заинтересовало ваше сообщении о новой книге, хотелось бы уточнить, когда она выходит и как ее можно будет заказать (а то тут у нас сложно с ХОРОШЕЙ литературой в магазинах :))) )? eggog@vao.udmnet.ru
С уважением? Игорь Корнилов.
Date: Mon, 4 Sep 2000 18:34:03
Здравствуйте, Юрий Алексеевич!
Случайно обнаружил Ваш сайт в бескрайнем мире Интернет и был приятно удивлен. Не каждый день встречаешь столько полезной информации в одном месте. Поскольку на сайте размещены обложки книг, то у меня возникло вполне определенное желание иметь эти книги в своей библиотеке. Если Вас не затруднит, подскажите, где их можно приобрести. При просмотре Вашего сайта у опытных пользователей возникает необходимость получения информации по какому-либо ключевому слову. Не могли Вы при дальнейшей работе учесть это и организовать самую простую поисковую машину. И еще вопрос. Не встречали ли Вы где-либо подробную информацию о коде hdb3? Если Вас не затруднит, дайте, пожалуйста, ссылочку на источник.
Спасибо Вам за то, что Вы делаете!
С уважением, Артем Глазунов, специалист Иркутского областного телеграфа.
e-mail: gav@irtel.ru
From: "Lex" <3694_KAN@nw.ie.tasur.edu.ru>
Organization: Industrial Electronics of TASCR
To: <semenov@itep.ru>
Date: Mon, 2 Oct 2000 19:40:23
В вашей книге "Протоколы Интернет" описан обработчик приема пакетов для пакетных драйверов receiver - он описан как процедура near а как сделать чтобы этот обработчик обращался к данным прикладной программы, например вставка в receiver строк типа
mov> ah,09h
lea dx,string
int 21h
Где string описана в данных прикладной программы приводит к выводу всякой ваты на экран и зависанию компа при обращении драйвера к receiverу причем $ на конце stringa не забыл указать и относительно другого сегмента пробовал (com программа) cs:[string] все равно Вы моя последняя надежда...
Date: Wed, 01 Nov 2000 11:53:59
Subject: Огромное СПАСИБО за то, что Вы есть!
У меня к Вам убедительная просьба отправить мне ответы на закрепляющие вопросы к теме "Каналы передачи данных" (http://book.itep.ru/) Я хотел бы проверить свои знания в этой области.
С уважением, Колот Сергей <kolot@mail.ru>
Date: Mon, 18 Dec 2000 00:49:29
Глубокоуважаемый Юрий Алексеевич!
Я хотел бы попросить Вас исправить русскоязычное написание имени и фамилии Michael Burrows'a -- одного из авторов WBT ("Burrows-Wheeler Transformation", also known as " Block Sorting"); его зовут Майкл Барроуз. Так получилось, что я работал в Великобритании и знаком с ним.
Спасибо, Андрей Кадач akadatch@microsoft.com
Здравствуйте,
Позвольте поблагодарить Вас, за тот труд, который Вы вложили в создание http://book.itep.ru/, он помог мне заполнить те пробелы в моих знаниях, которые долгое время не давали мне покоя. Спасибо.
Вы пишите:
> Во-первых, ограниченность времени и жанр лекций не позволяют разместить полные
> описания протоколов (конспективность здесь неизбежна) и представить необходимые
> справочные материалы...
Не могли бы Вы подсказать, где можно найти более полную информацию, касающуюся вопросов моделирования и оптимизации сетей. Заранее благодарен.
Kirill V. Krinkin
mailto:krinkin@mailru.com
Brainbench Public Transcript: 173921,
http://www.brainbench.com/transcript.jsp?pid=173921
7 января 2001 г.
Date: Mon, 05 Feb 2001 16:44:31
Здравствуйте. Пишет вам Константин из города Луганска. Я ищу описание дельта кодака. К сожалению я не знаю его точного названия, но знаю что в данном протоколе используется метод адаптивной дельта модуляции, частота передачи 32 Кбит/сек, и на одну линию подсоединяется 8 цифровых т/а. Если описание подобного протокола в вашей книге?
e_mail: kos_k@inbox.ru
Thu, 15 Feb 2001 22:31:43
From: "I. F." <code@dir.bg>
To: <semenov@itep.ru>
Date: Thu, 15 Feb 2001 21:33:47
bravo bravo good book:
about <http://book.itep.ru/1/intro1.htm>
Date: Thu, 22 Feb 2001 17:40:26
Здравствуйте!
Я хотел бы узнать, где можно найти вашу книгу "Telecommunication technologies - телекоммуникационные технологии” в электронном виде.
Алексей В. Майоров МФТИ ФПМЭ. lexa@megasoft.ru
Date: Mon, 12 Mar 2001 18:25:34
Уважаемый Юрий Алексеевич, меня очень понравился сайт (<http://book.itep.ru/>)с вашими книгами. Я осваиваю программирование под Windows, с уклоном в сетевые технологии, и столкнулся с тем, что в Инете очень мало информации по этой теме, на русском языке, поэтому приходилось искать на буржуйских сайтах, но в силу слабости моих познаний английского, меня этот путь не совсем устраивает, и сегодня блуждая по поисковикам наткнулся на вашу главу , посвященную Сокетам, мне она очень понравилась, благодаря своему подробному описанию данного вопроса. Затем посмотрел на оглавление, мне понравилось еще больше, показал друзьям - программистам - они тоже оценили. По моему мнению, это лучшая книга по обработке информации, и сетевым технологиям (по крайней мере среди русскоязычных). Выражаю Вам огромную признательность от своего имени за проделанную колоссальную работу в области развития информационных технологий среди начинающих программистов(и профессиональных также):).
В заключение, хотелось бы узнать, изданы ли они в печатном виде и, если да, то где их можно приобрести
С уважением, Вячеслав Потапов, студент МИСиС. VPotapov@estra.ru
Date: Wed, 28 Mar 2001 14:52:42 +0400
From: "maks" <imv@ghost.dn.ua>
Пишет вам студентка Украинской Государственной Академии связи, мой преподаватель выдал мне диплом на тему "видеотелеконференции – как услуга центра документальной электросвязи ", сославшись на то что поискать информацию по этой теме можно в ваших книгах. Причем, какие конкретно книги он мне не сказал. Если вас не затруднит, напишите пожалуйста по этому адресу, какие книги на интересующую меня тему вы написали. Или, если можно и есть публикации в Интернете скиньте пару ссылок на них.
заранее благодарна!
Best regards,
Марина mailto:imv@ghost.dn.ua
From: "Digitman" <digitman@dax.ru>
To: <semenov@itep.ru>
Date: Tue, 3 Apr 2001 13:01:37
Добрый день, ув. Ю.А.!
С интересом проштудировал раздел "Сокеты" http://book.itep.ru
В наст. момент я занимаюсь разработкой пакета Делфи-компонентов, реализующих логику клиент-серверного взаимодействия не базе гнезд. Общая идея, подвигнувшая меня на разработку, заключалась в усовершенствовании базовых решений данных технологий, представленных в виде устойчивых классов TServerSocket и TSocketConnection, c учетом преимуществ технологий MIDAS и ASTA. Не могу утверждать об идеальном понимании мной в данный момент концепции гнезд TCP/IP, но стремление к совершенству результата требует того.
В связи с этим я столкнулся с малопонятой и малодокументированной проблемой, возникающей при использовании сокет-сервером логики установления коннекта с сокет-клиентом с использованием расширенной ф-ции WSAAccept() вместо стандартно применяемой в компонентах VCL Accept():
Я использую гнезда в режиме SOCK_STREAM. По специф-ции MS Winsock2 ф-ция> WSAAccept() должна позволять принимать/отвергать/откладывать вх запросы клиентских гнезд на установление коннекта. С этой целью в Проблемная ситуация состоит в следующем:
1. Если ConditionFunc() возвращает CF_REJECT (отвергнуть вх.запрос на соединение), то WSAAccept() работает правильно, возвращая INVALID_SOCKET, НО клиентский вызов connect(), запросивший соединение, завершается УСПЕШНО, сигнализируя об установлении соединения, ХОТЯ сервер ОТВЕРГ его!
2. Если ConditionFunc() возвращает CF_DEFER (отложить рассмотрение вх.запроса на соединение, не уничтожая его в очереди BackLog), то WSAAccept() работает правильно, возвращая INVALID_SOCKET, НО ТОЛЬКО при первом ее вызове. Повторные вызовы WSAAccept() (как правило, этот вызов - блокирующий и вложен в цикл в отдельном потоке) предполагают повторные проверки условий ф-цией ConditionFunc() для очеред.элемента из BackLog-очереди, которым может оказаться и только что отложенный запрос (!), НО почему-то вызова callback-функции проверки условий в этом случае не происходит !!!! Вместо этого WSAAccept() безусловно возвращает дескриптор нового сокета для вновь установленного соединения (а может, мне его снова нужно было бы отложить? или отвергнуть по каким-либо причинам ?).
САМОЕ ПЕЧАЛЬНОЕ, что при любом раскладе клиентское гнездо СРАЗУ ЖЕ получает подтверждение постановки запроса со стороны "слушающего" серверного гнезда, если сервер вовремя вызвал Listen() и параметры (IP-адрес и порт) кл.гнезда указаны корректно, хотя в этот момент сервер еще не принял решения об акцепте запроса !!!!! Т.е., подтверждение сервером получения клиентского запроса на установление соединения выглядит на клиентской стороне как реальный (а не виртуальный) коннект, и клиент может развернуть последовательность зависимых от успешного коннекта действий (например, начать формирование буфера передачи), не подозревая, что через доли секунды произойдет дисконнект, связанный с отвержением запроса.
Где здесь"зарыта собака" ?
Можно ли обойти проблему и каким образом ?
Слышал, что MS намеренно реализовал такую логику с целью, якобы, минимизации времени на установление коннекта. Но - жесткая ли она, эта логика ? Как ее обойти, возможно, заданием спец. опций TCP-протокола (или QOS) ?? Можно ли найти более-менее понятные и надежные примеры реализации "верной по сути" логики ? (неважно, на чем сверстанные). Есть ли в сети сайты/форумы, посвященные данным проблемам, желательно, в Рунете? Заранее признателен Вам за внимание. Надеюсь на любую помощь в возникших у меня вопросах с учетом Вашей компетенции.
Date: Mon, 9 Apr 2001 13:41:42
Уважаемый госп. Семенов!
Не могли бы Вы сообщить об условиях размещения информации о компании "Атлант_Информ", являющейся разработчиком сертифицированной АСР для телекоммуникационных предприятий "Атлант" на Вашем сайте в рубрике 10.11 "Адреса фирм, работающих в сфере телекоммуникаций". Заранее благодарна, начальник отдела по связям с общественностью компании "Атлант-Информ"
Наталья Лыкова. <market@atlant-inform.ru>
From: "Shefanovski Dennis" <shefanovski@infosec.ru>
To: <semenov@itep.ru>
Date: Tue, 3 Apr 2001 06:20:34
Посмотрел и стало грустно...
Прочитайте документацию, есть ведь даже модели конечных состояний клиента и сервера.
Так нельзя.
PS Я прекрасно понимаю, что все охватить невозможно, но все же
Best regards! DennisShefanovski <shefanovski@infosec.ru>
Это единственный негативный отклик. Именно по этой причине позволю себе краткий комментарий. Во-первых у меня давно устойчивая аллергия на машины конечных состояний. Во-вторых, с моей точки зрения нужно быть большим педантом, чтобы диалоговый алгоритм описывать с помощью формализма FSM. Скажем, протокол TCP, еще куда ни шло, а SSL, эту уж действительно чересчур. В-третьих, то, что помещено на сервере, взято было со страницы компании NetScape. Но, признаю, нет предела совершенству, и я не хотел бы утверждать, что создал образец для подражания. Интернет прекрасен тем, что если вы знаете как что-то сделать лучше, - сделайте это и дайте другим воспользоваться.
Date: Fri, 20 Apr 2001 16:46:44
Уважаемый Юрий Алексеевич, внимательно прочел материалы, размещенные Вами на сервере http://book.itep.ru/ под общим названием Telecommunication technologies - телекоммуникационные технологии.
Особенно интересным мне показался раздел о диагностике сетевого оборудования. Вы приводите описание программы для мониторинга состояний серверов в сети; не могли бы Вы (если, конечно, это возможно) сообщить адрес электронной почты разработчика этой программы (конечно, с его согласия) - мне очень нужна консультация по вопросам, связанным с мониторингом состояния серверов в internet.
С уважением, Дмитрий <meditech@spb.cityline.ru>
Date: Wed, 16 May 2001 04:04:29
Добрый день, уважаемый Семенов Ю.А.
Простите за беспокойство, но может быть Вы сможете мне помочь. Меня зовут Александр, я программист из Киева. Раньше мне никогда не приходилось сталкиваться с задачами
телекоммуникаций, но по работе срочно необходимо написать программу
демодуляции фазоманипулированных сигналов PSK, BPSK, QPSK (источник - звук, принимаемый SoundBlasterom).
Если Вас не затруднит, не могли бы Вы подсказать мне алгоритм, принцип, формулы, что угодно, для демодуляции этих сигналов. Или, по меньшей мере, подскажите, где можно об этом прочесть (книги, Internet).
Заранее крайне Вам признателен.
Александр. <VORONUK@APORT.RU>
Date: Sat, 2 Jun 2001 15:38:00
Добрый день.
Заходил к Вам на сайт, узнал о кафедре "Телекоммуникационные сети и системы". Подскажите? пожалуйста, есть ли у Вас дистанционная, либо заочная форма обучения и каким специальностям у Вас обучают.
С уважением, Анфёров Евгений
Инженер ЭВМ ООО "СК Мост"
676850, г. Белогорск ул. Кирова 279 "Б"
E-Mail: jon@most.com.ru
ICQ# 23629387
www.skmost.ru
Date: Mon, 11 Jun 2001 10:54:20
Добрый день!
У меня к вам большая просьба!
Мне срочно нужна информация по написанию драйверов для сетевого адаптера под MS-DOS (для диплома). Подскажите pls, где можно ее найти. (мои поиски пока ни к чему не приводят, кроме вашей статьи "Программирование при работе с TCP/IP пакетами"). Заранее благодарен,
Александр <phoenix@aib.ru>
P.S. Нет так нет (буду искать)
From: "Alexandr Ivanov" <ivanov@kons.ru>
To: <semenov@itep.ru>
Здравствуйте, Юрий Алексеевич!
Сегодня случайно наткнулся в сети на Вашу книгу. Очень полезное и необходимое издание. Хочу просить Вашего разрешения на зеркалирование этого сайта... Я исключаю любое коммерческое использование. Хочу просто создать копию у себя на сервере и продвигать этот ресурс среди своих клиентов. Компания, в которой я работаю, является крупнейшей телекоммуникационной компанией в регионе. Среди наших клиентов 80% провайдеров города Саратова.
Жду Вашего ответа. Спасибо.
С Уважением, Александр Иванов
Начальник отдела ИТ ЗАО "Конверсия-связь"
______________________________________________
AI1410-RIPE mailto:ivanov@kons.ru +7 845 2450544
Date: Wed, 27 Jun 2001 10:26:15
Здравствуйте, Юрий Алексеевич!
Все наши ресурсы построены именно таким образом, что тексты и рисунки лежат в какой-то базе данных. А дизайн - это 2-3 шаблона. Именно из-за того, что информация на Вашем сайте постоянно обновляется и нужен такой вариант, чтобы не выкачивать страницы целиком. а только обновления базы. Цель, которую я преследую такова: есть необходимость иметь локально нужный, интересный и полезный ресурс и пропагандировать его среди своих клиентов. Клиенты создают трафик, чем он больше, тем дешевле стоит и для меня и для клиентов. По-поводу идей: направляю Ваше письмо своему WEB-мастеру. Думаю, он сможет что-то предложить. Адрес, где будет размещено зеркало: book.kons.ru , но это будет позже, когда мой администратор вернется из командировки (на следующей неделе).
С Уважением,
Александр Иванов
Директор департамента ИТ ЗАО "Конверсия-связь"
______________________________________________
AI1410-RIPE mailto:ivanov@kons.ru +7 845 2450544
Date: Tue, 03 Jul 2001 19:05:35>
Здравствуйте!
Я обнаружил вашу электронную версию книги "Сети Интернет" Скажи, пожалуйста есть ли у вас версия в PDF и где её можно найти?
С Уважением М.А. Пикулин
Молоток: от Фаберже до неглиже
http://www.molotok.ru/?190
Date: Mon, 9 Jul 2001 17:40:10
Добрый день!
Если у Вас, есть информация по аналоговым интерфейсам:
e&m (типы 1, 2, 3, 4, 5 )
ls/gs Subscriber (FXS)
ls/gs Exchange (FXO)
MRD
по цифровым
v.24/v.28/rs-232c
rs-530-a, v.36/rs-449, x.21 и x.35
OCU-DP
G.703 сонаправленный 64 кбит/с......
и возможность, вышлите ее (информацию), пожалуйста, на evsve@mail.ru
с уважением, Евграфов Сергей!
Date: Thu, 9 Aug 2001 12:34:56
Уважаемый господин Семенов Ю.А.
Должен Вам сообщить о некоторой неточности, которая присутствует в перечислении компаний, работающих в области телекоммуникаций. ( сайт http://book.itep.ru/1/intro1.htm раздел 10). Компаний Wandel Goltermann и Wavetek в настоящее время не существует, т к в 1998 году они путем слияния были преобразованы в корпорацию Wavetek Wandel Goltermann с соответствующим сайтом в Интернете www.wwgsolutions.com. Однако это не последнее преобразование фирмы. В 2000 году произошло следующее слияние компаний WWG и американской ТТС. В результате образованная компания получила название ACTERNA. Именно под этим названием компания и работает в настоящее время. Сайт в Интернете называется - www.acterna.com (или российский сайт - www.acterna.ru)
Date: Sat, 6 Oct 2001 18:22:46
From: "profy.ru" <info@profy.ru>
To: semenov@itep.ru
Уважаемые господа!
Разрешите предложить Вашему вниманию для возможного размещения в разделе ссылок Вашего сайта наш Интернет-проект "Мир Профессионалов"- www.profy.ru . Это универсальный кадровый сервер, с которым сотрудничают и размещают свои вакансии более 1500 компаний и кадровых агентств. Все размещаемые вакансии модерируются, то есть исключены вакансии от недобросовестных работодателей. Надеемся, ссылка на www.profy.ru окажется интересной для Ваших посетителей. Кнопку сайта можно выбрать здесь - http://moscow.profy.ru/linktoprofy.phtml
С наилучшими пожеланиями,
Владимир Ершов,
менеджер проекта
www.profy.ru
info@profy.ru
Date: Fri, 19 Oct 2001 02:34:33
Здравствуйте, Юрий Алексеевич.
Спасибо Вам за Вашу электронную книгу по сетям. Впечатляет. Имеется ли что-нибудь по программированию, по дискретной и вычислительной математикам.
С уважением
Александр Суворов
Best regards,
Alexandre mailto:spartak@nojabrsk.ru
Date: Thu, 25 Oct 2001 21:44:41
Здравствуйте господин Семенов !
Меня зовут Олег. Я столкнулся с необходимостью получения документации по протоколу Х500. В рунете я нашел вашу статью на эту тему, но предложенной там информации оказалось недостаточно. Не могли бы вы, если вас не затруднит, подсказать на каких русскоязычных ресурсах можно найти информацию на эту тему. Заранее вам благодарен.
solid82@rambler.ru
Бесплатная почта http://mail.Rambler.ru/
Рамблер-Покупки http://ad.rambler.ru/ban.clk?pg=1691&bn=9346
Date: Wed, 12 Dec 2001 15:24:57
Здравствуйте Юрий Алексеевич,
Недавно наткнулся на ?кусочки? ваших электронных лекций у одного из своего знакомых. Очень заинтересовался вашим материалом, но к сожалению, ваших книжек в продаже не нашел. Если вас не затруднит, пожалуйста, напишите, где можно заказать или пробрести вашу литературу, CD (если он вышел) и вышли ли ваши новые труды после ?Протоколы и ресурсы Интернет? (Радио и связь, М. 1996) и "Сети Интернет. Архитектура и протоколы? (Сиринъ, М. 1998).
Заранее благодарен,
с уважением, студент 4-го курса СПбГТУ
Бесплатная почта http://mail.Rambler.ru/
Date: Wed, 29 May 2002 13:03:21
Уважаемый Юрий Алексеевич!
Большое спасибо за вашу работу, результатами которой очень приятно пользоваться (а главное с пользой). На сервере представлено очень много информации, но доступ к ней удобен только для тех, кто имеет постоянный доступ в сеть. Не планируете ли вы выкладывать для скачивания оффлайновую версию сайта? george@comtv.ru
From: "Eugene Rybakov" <rybakov@bhv.ru>
To: <semenov@itep.ru>
Date: Thu, 11 Apr 2002 13:07:37
..Данный сервер частично создан на средства, выделенные по проектам РФФИ (99-07-90102 и 01-07-90069). В основу материалов легли тексты книг автора "Протоколы и ресурсы Интернет" (Радио и связь, М. 1996) и "Сети Интернет. Архитектура и протоколы" (Сиринъ, М. 1998), а также "Протоколы Интернет. Энциклопедия" ("Горячая линия - Телеком", М. 2001), которые базировались на двух курсах, читаемых студентам кафедры "Телекоммуникационные сети и системы" МФТИ (факультет ФПФЭ) - "Каналы и сети передачи данных", "Протоколы Интернет".
...данное направление науки и технологии развивается стремительно и отследить прогресс в этой отрасли с использованием техники книжных издательств практически невозможно (первая книга готовилась к печати с уровня машинных файлов около года, вторая - 4 месяца). Автор решил попытаться решить эту проблему методами современных сетевых технологий.
Уважаемый Юрий Алексеевич!
Если Вы не разочаровались окончательно в технике книжных издательств, прошу обратить внимание на возможность издания очередной книги в "BHV-Петербург". Тематика нас весьма интересует.
Рассмотрим встречные предложения.
Евгений Рыбаков, научный редактор.
From: "AdminAtlas" <kisasoft@atlas-nsk.ru>
To: <semenov@itep.ru >
Date: Wed, 11 Sep 2002 12:33:00
Прошу Вашего согласия на размещение текста сайта http://book.itep.ru/ у себя на сайте http://www.atlas-nsk.ru в одном из разделов посвященных сходной тематике. Сохранность авторской редакции текста гарантирую. Ссылки на автора будут установлены. Жду ответа.
С уважением . Семенов Юрий Анатольевич.
From: <safonov@tih.ru>
To: <semenov@itep.ru >
Date: Wed, 27 Nov 2002 09:58:34
Здравствуйте, Юрий Алексеевич.
Совершенно случайно нашел Ваш сайт "телекоммуникационные технологии". Огромное спасибо за него! Я только начинаю администрить и он уже стал моим "настольным" справочником.
С уважением, Сафонов Андрей
mailto:safonov@tih.ru
www.tihoretsk.ru
Параллельный сетевой интерфейс HIPPI
4.1.7 Параллельный сетевой интерфейс HIPPI
Семенов Ю.А. (ГНЦ ИТЭФ)
Все рассматриваемые до сих пор системы передачи информации использовали исключительно последовательный код. На разных этапах эволюции телекоммуникаций предпочтение отдавалось и параллельному и последовательному методам обмена данными. В данный момент параллельный интерфейс сохранился только для подключения принтеров. Главным преимуществом последовательных схем передачи информации является экономия на кабелях. Ниже описан еще один стандарт, где применен параллельный интерфейс (начало разработки относится к 1987 году). HIPPI (high performance parallel interface, смотри ftp.network.com;
http://www.cern.ch/hsi/hippi/spec/introduc.htm; RFC-2067, IP over HIPPI, J.Renwick; RFC-1374, IP and ARP on HIPPI, J.Renwick, ANSI x3t9.3/90-043, 1990 и X3t9.3/91-005) представляет собой быстродействующий параллельный интерфейс, рассчитанный на пропускную способность 800 Мбит/с (но возможны версии со 100, 200 400 и 1600 Мбит/с). Разработка интерфейса выполнена в Лос-Аламосе. Позднее на базе этого интерфейса была подготовлена идеология сети.
Длина кода, передаваемого за один такт в HIPPI, составляет 32 разряда (версия HIPPI, рассчитанная на скорость 1600 Мбит/с, имеет длину кода 64 бита). Все пересылки являются симплексными. Существует стандарт Superhippi (HIPPI-6400, 6,4 Гбайт/с), который описывает систему передачи данных в 8 раз более быстродействующую, чем HIPPI. Разработана версия последовательного HIPPI на скорость обмена 1,2 Гбод для коаксиального и оптоволоконного кабеля (до 10км; версия HIPPI-FC – fiber channel). Максимальное расстояние между станцией и переключателем составляет 25 м. Максимальное дистанция между станциями (станция-переключатель-станция) равно 50 м. Предельное число станций зависит от типа используемых переключателей. Переключатели могут взаимодействовать друг с другом (HIPPI-SC), обеспечивая информационный обмен между станциями. Пример топологии сети hippi представлен на рис. 4.1.7.1.
Рис. 4.1.7.1. Пример топологии сети hippi (П – переключатели, С – станции)
HIPPI предполагает передачу данных по медному кабелю (или оптическому волокну) только в одном направлении по схеме связи точка-точка, но два канала HIPPI могут обеспечить и двунаправленный обмен данными. Передающий кабель может содержать 50/100 скрученных пар или соответствующее число оптических волокон. Длина пакета данных может варьироваться. Протокол HIPPI рассчитан на работу в реальном масштабе времени при суммарных длинах кабелей до десятков километров. Стандартный блок данных содержит 256 слов (1024 или 2048 байт). Для контроля корректности передачи предусмотрен контроль по четности для каждого байта на шине, кроме того, для каждого блока данных вычисляется “продольная” контрольная сумма (LLRC - length/longitudinal redundancy checkword). На рис. 4.1.7.2 показана схема передачи данных в рамках протокола HIPPI. На каждое соединение может быть передано любое число пакетов, пакет в свою очередь может содержать любое число блоков. Время между пакетами не регламентировано и может меняться, оно зависит от потока данных и протокола верхнего уровня.
Рис. 4.7.1.2. Структура передаваемой информации (каждое слово содержит 32 или 64 бита)
Каждый пакет содержит в конце субполе контроля четности. Все сигналы кроме соединения (interconnect) используют приемники и передатчики эмиттерно-связанной логики (ECL). Формат I-поля показан на рис 4.1.7.3.
Рис. 4.1.7.3. Формат i-поля пакета HIPPI
Поле L=1 – локально заданный формат; W=1 указывает на 64-битное соединение; D=1 отмечает смену положения адресов отправителя и получателя; PS – биты выбора пути (path selection); С – задержка вызова при занятой линии (camp-on; переключатель не разрывает соединения при занятом получателе, а ждет его освобождения). 12-битовые адреса отправителя и получателя часто делятся на 6-битовые секции, определяющие адрес переключателя и номер порта. HIPPI-IPI (intelligent peripheral interface) представляет собой быстродействующий интерфейс периферийных устройств, выполняющий команды SCSI. Расширение HIPPI-LE (link encapsulation) обеспечивает поддержку IEEE 802.2.
При расстояниях до 25 метров используется кабель, содержащий 50 скрученных пар. Такты часов следуют с периодом 40 нсек. В сетях HIPPI предусмотрен транзит пакетов формата TCP/IP. Блок-схема канала HIPPI показана на рис. 4.1.7.4.
Рис. 4.1.7.4. Блок-схема канала HIPPI
Существуют документы, регламентирующие работу системы передачи информации HIPPI для основных уровней интерфейса, начиная с физического. Предусмотрена работа HIPPI с протоколами TCP/IP. Смотри также "ARP and IP Broadcast over HIPPI-800". J.-M. Pittet. May 2000, RFC-2834, "IP and ARP over HIPPI-6400 (GSN)". J.-M. Pittet. May 2000, RFC-2835.
Передача голоса по каналам Интернет
2.4.3 Передача голоса по каналам Интернет
Семенов Ю.А. (ГНЦ ИТЭФ)
Несколько лет назад появился новый вид услуг в Интернет - голосовая связь (IP-phone, Vocaltec). Сегодня имеется 30 миллионов абонентов, регулярно пользующихся IP-phone и его аналогами, ожидается до 200 миллионов до конца текущего десятилетия, качество передачи постепенно приближается к уровню цифровой телефонии.
Среди пользователей есть те, для кого это лишь возможность общения, как для радиолюбителей; но все больше людей использует IP-phone для деловых контактов или даже как объект бизнеса.
Существуют два алгоритма сжатия звуковой информации, используемых для ip-телефонных переговоров: GSM (global system for mobile communications, ftp.cs.tu-berlin.de/pub/local/kbs/tubmik/gsm), которая обеспечивает коэффициент сжатия 5, и алгоритм DSP-группы (true speech) с коэффициентом сжатия данных 18 (работает при частотах 7.7 кбит/с). Добавление аппаратных средств сжатия информации позволяет сократить необходимую полосу до 6.72 Кбит/с. Потеря 2-5% пакетов остается незамеченной, 20% оставляет разговор понятным. В таблице 2.4.3.1 представлена зависимость необходимой полосы телекоммуникационного канала от частоты стробирования звукового сигнала, которая определяет качество воспроизведения.
Таблица 2.4.3.1.
| Пропускная способность |
Частота стробирования |
9600 |
4000 |
14400 |
6000 |
19200 |
8000 |
28800 |
11000 |
Для подключения к сети ip-phone необходима мультимедийная карта, микрофон, динамики (или наушники), 8 Мбайт оперативной памяти, доступ к Интернет и соответствующее программное обеспечение. Качество передачи звука зависит от загруженности IP-канала. В качестве транспорта используется протокол UDP. Для обеспечения высокого качества звука нужна гарантированная ширина IP-канала, ведь задержанные сверх меры UDP-дейтограммы теряются безвозвратно, что и приводит к искажениям. Внедрение протоколов, гарантирующих определенную ширину канала сделают IP-phone значительно более привлекательным. Многие компании уже предлагают такое оборудование и программы. Программы и описания этого вида услуг можно найти по адресам:
ftp://cs.ucl.ac.uk/mice/videoconference
http://www.pulver.com/netwatch
http://www.planeteers.com
http://www.newparadigm.com
http://www.vocaltec.com
http://www.itelco.com
http://www.quarterdeck.com
В последнее время технология передачи звука по каналам Интернет стала широко использоваться для трансляции новостей и музыки. При этом обеспечивается вполне удовлетворительное качество даже при передаче стерео программ. В этом случае имеется возможность применить более эффективное сжатие информации и протоколы типа RTP и RTCP. Задержка при передаче в этом случае никакого значения не имеет, а качество доставки гарантировано. Современные системы ip-телефонии снабжены гибкой системой буферов, позволяющих использовать для передачи паузы, когда один из партнеров молчит. (См. также "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. H. Schulzrinne, S. Petrack. May 2000" RFC-2833 и "URLs for Telephone Calls. A. Vaha-Sipila. April 2000". RFC-2806).
В настоящее время имеется практически полный набор технологий, чтобы создать электронную книгу. Такая книга будет представлять собой систему размером с ноут-бук, снабженное устройством для чтения CD-дисков. Текст книги вместе с иллюстрациями и необходимыми командными последовательностями записывается на CD. При этом в перспективе можно рассматривать возможность того, что такое устройство будет читать "книгу" вслух (вывод на наушники). В настоящее время имеется достаточно большое количество книг, записанных на cd. Это, прежде всего, энциклопедические словари, альбомы музеев, библия и многие другие. Преимущество такой формы книги уже сегодня ощутимо - вы можете использовать современные поисковые средства, чтобы найти нужный раздел или какую-то конкретную информацию. По мере развития этой технологии и интеграции ее с сетями можно будет осуществлять поиск не только по данной книге, но и по книгам или журналам, ссылки на которые в данной книге содержатся, что может быть особенно полезно при первичном знакомстве с какой-то проблемой. Я здесь не говорю о компактности, а в перспективе, и долговечности такой формы записи информации. При звуковом воспроизведении читатель сможет выбирать, голосом какого актера или актеров будет читаться данная книга. Разумеется, для этого не потребуется начитывать данный текст самим актерам. Достаточно иметь запись характерных особенностей голоса и интонаций конкретного голоса, а процессор сам при генерации звука будет использовать голосовые особенности того или иного человека. Немного фантазии и можно будет представить, как ЭВМ будет воспроизводить текст в виде фильма, который она сгенерировала по выданному ей тексту (ведь сгенерирован же на ЭВМ корабль "Титаник" и море, по которому он плывет). Аналогичные услуги смогут оказываться и через сеть Интернет. Наибольшие трудности вызовет реализация качественного воспроизведения. Программы способные преобразовывать символьный текст в голос уже существуют. Проблема распознавания индивидуального голоса давно решена в охранных системах. Осталось научиться использовать результаты такого анализа при воспроизведении.
Активно разрабатываются многие новые стандарты и протоколы для обеспечения передачи звука по ip-каналам, проведения видеоконференций и управления в реальном масштабе времени. К таким протоколам относятся RTP (real time protocol, RFC-1889, -1890), RTCP (real-time control protocol), который является дополнением RTP, и RSVP (resource reservation protocol, см. разделы проектов IETF nic.nordu.net, ftp.isi.edu, munnari.oz.au и ds.internic.net или ftp.ietf.org/internet-drafts/draft-ietf-rsvp-spec-16.txt), служащий для обеспечения своевременной доставки данных при работе в реальном времени. Протокол RTP способен работать помимо UDP/IP в сетях CLNP, ATM и IPX. Он обеспечивает детектирование потерь, идентификацию содержимого, синхронизацию и безопасность (доступ по шифрованному паролю, см. RFC-1423). Проблема синхронизации при передаче звука особенно важна, так как даже для локальных сетей время доставки пакетов может варьироваться в весьма широких пределах из-за используемого алгоритма доступа (например, CSMA/CD), а это приводит к искажениям при воспроизведении. Протоколы RTP и RTCP позволяют одновременное голосовое общение неограниченного числа людей в рамках сети Интернет. Протокол же RSVP (или его аналог) в случае внедрения гарантирует качество связи (разумеется, при достаточной широкополосности канала) за счет повышения приоритета пакетов реального времени. Следует иметь в виду, что голосовое общение, хотя и весьма привлекательно, не является единственной и даже главной целью разработчиков. По мере совершенствования протоколов Интернет сделает возможным управление в реальном масштабе времени довольно сложными удаленными объектами.
В таблице 2.4.2 представлены характеристики аудио-кодеков, которые можно использовать в IP-телефонии.
Таблица 2.4.2. Характеристики аудио-кодеков
Кодек |
Выходная скорость кодека |
G.711 |
64 кбит/с |
g.723.1 |
5,3 или 6,4 кбит/с |
g.722 |
48, 56 или 64 кбит/с |
g.728 |
16 кбит/с |
g.728/g.729a |
8 кбит/с |
При внедрении ip-телефонии желательно, чтобы сетевая инфраструктура обеспечивала:
Время задержки в одну сторону менее 100 мсек.
Вероятность потери пакета менее 5%.
Оборудование должно соответствовать требованиям H.323v2, а механизмы безопасности - стандарту H.235.
Наличие функции привратника в маршрутизаторе/шлюзе (блокирует установку новых телефонных соединений при отсутствии необходимых ресурсов)
Одна из возможных реализаций IP-телефонии показана на рис. 2.4.3.1. (MVD – Multiflex Voice/WAN модуль, включаемый в маршрутизатор, например, Cisco-3662).
Рис. 2.4.3.1. Пример реализации системв IP-телефонии
На рисунке MVW-модуль (Multiflex Voice/WAN), включаемый в маршрутизатор, например, CISCO-3662, служит для связи с общедоступной телефонной сетью. Если сеть “А” размещена в Рио-де-Жанейро, а “В” в Москве, то любой клиент нижней сети сможет разговаривать с клиентом в Рио “бесплатно”, а с клиентами телефонных сетей “А” и “B” по локальным тарифам. В левой части рисунка показаны телефонные аппараты, которые подключаются непосредственно к сегменту локальной сети. Такие приборы уже поступили в продажу.
Связь может осуществляться как с традиционной старой аналоговой телефонной сетью, так и с ISDN. Телефонные аппараты могут подключаться непосредственно к интерфейсу маршрутизатора, к сетевой рабочей станции или к специальному сетевому адаптеру.
Передача сигналов по линиям связи
2.1 Передача сигналов по линиям связи
Семенов Ю.А. (ГНЦ ИТЭФ)
Теорема Шеннона ограничивает предельную пропускную способность канала I с заданной полосой пропускания F и отношением сигнал/шум S/N :
[2.1]
Для стандартного телефонного канала F=3кГц, N/S=30db, следовательно, теоретический предел для публичной коммутируемой телефонной сети равен примерно 30кбит/с. Ослабление для телефонных скрученных пар составляет около 15 дБ/км, дополнительные ограничения возникают из-за перекрестных наводок. Стандартные проводные линии связи имеют ослабление 6 дБ/км на частоте 800 Гц, или 10 дБ/км на частоте 1600 Гц. На рис. 2.1.1 показана зависимость ослабления от частоты передаваемого сигнала для медной линии с сечением 0,5 мм.
Рис. 2.1.1. Зависимость ослабления сигнала в медной линии сечением 0,5мм от частоты
От частоты зависит фаза (из расчета на километр) и волновое сопротивление скрученной пары (см. рис. 2.1.2), по этой причине искажения формы сигнала при заметной длине линии неизбежны.
Из формулы [2.1] видно, что расширять пропускную способность канала можно за счет широкополосности и высокого отношения сигнал-шум. Существует много источников шума, один из главных тепловые шумы (N = kTB, где T – температура в градусах Кельвина, B – полоса пропускания приемника, а k – постоянная Больцмана). На практике существенно большее влияние оказывают различного рода наводки. Увеличeние пропускной способности сети достигается путем сокращения длины кабеля (уменьшение расстояния между узлами сети), заменой типа кабеля, например, на провод с большим сечением, или применив оптоволоконный кабель. Определенный эффект может быть получен и с помощью усовершенствованной системы шумоподавления (новый, более эффективный модем).
Рис. 2.1.2. Зависимость волнового импеданса скрученной пары и фазы (сечение 0,5мм) от частоты
Сопротивление скрученной пары от коммутатора до терминального оборудования может лежать в пределах 800-20000 Ом. Следует учитывать, что при подаче питания на терминальное оборудование (телефон) по подводящему кабелю, большое его сопротивление, помимо прочего, приведет к падению питающего напряжения. В многожильных кабелях определенные проблемы создают перекрестные наводки и шумы. Обычно рассматриваются два случая перекрестных наводок:
Источник сигнала и приемник находятся по одну сторону кабеля (NEXT - near end crosstalk);
Приемник и источник находятся на разных концах кабеля (FRXT - far end crosstalk).
NEXT-наводки при большом числе пар проводов в кабеле подчиняются закону f1.5 , а их уровень составляет около 55 дБ при частоте 100 кГц. FEXT-наводки сильно зависят от схемы коммутации и разводки проводов и обычно менее опасны, чем NEXT. Еще одним источников наводок является импульсный шум внешних электромагнитных переходных процессов. Этот вид наводок обычно характеризуется процентом времени, в течении которого его уровень превышает порог чувствительности, и варьируется в зависимости от обстоятельств в очень широких пределах.
При передаче по линии сигналы модулируются, при этом важно обеспечить сохранение среднего уровня сигнала (постоянной составляющей). Определенные искажения сигнала вносит сам кабель. Заметное влияние на характер искажений оказывает межсимвольная интерференция (ISI - Intersymbol Interference). Эта интерференция возникает из-за расплывания импульсов в процессе их передачи по линии и наезжания их друг на друга. Проблема усложняется тем, что характеристики передающей линии могут меняться со временем (коммутаторы и маршрутизаторы). По этой причине очень важно обеспечить идентичность условий передачи различных частот при наличии таких вариаций. Для решения этой задачи используются линейные эквилайзеры (рис. 2.1.3 и 2.1.4), которые выполняют эту операцию во всем спектре частот, или после стробирования для реального спектра сигнала. Этот метод чувствителен к шумам в системе. Эквилайзеры с решающей обратной связью (DFE - Decision Feedback Equalizer) не чувствительны к шумам, они управляются принятой информацией. Но влияние ошибок при приеме информации в этом случае может быть усилено.
Рис. 2.1.3. Линейное выравнивание (эквилизация)
Рис. 2.1.4. Эквилизация с помощью решающей обратной связи
На практике линейное выравнивание и эквилизация с обратной связью совмещаются друг с другом и со специальными методами формирования передаваемых сигналов. Проблема усугубляется тем, что одна и та же линия используется для передачи данных в обоих направлениях одновременно.
Для улучшения отношения сигнал/ шум следует поднимать амплитуду передаваемого по линии сигнала. Выбранное значение определяется требованиями перекрестных наводок и возможностями существующих БИС. В результате компромисса выбрана амплитуда 2.5 В на нагрузке 135 ом. Любые нелинейные искажения должны быть менее 36 дБ по отношению к основному сигналу. Учитывая динамический диапазон сигналов в линиях связи, отношение сигнал шум предполагается равным 20 дБ, что соответствует ограничению 6дБ на число ошибок 1/106 для гауссова распределения шума. При аналого-цифровом преобразовании одному биту соответствует 6 дБ.
Обычно двухпроводная линия (тем более 4-х проводная) используется для одновременного двухстороннего обмена (full duplex). Эта задача может быть решена схемотехнически мультиплексированием по времени (TDD - Time Division Duplex) или частоте (FDD - Frequency Division Duplex). TDD довольно легко реализовать, этот метод не требует сложных фильтров и эквилайзеров. Метод TDD привлекателен при малых длинах кабеля для коммутируемых телефонных сетей.
Рис. 2.1.5. Схема эхо-компенсации
Более широко для реализации двухстороннего обмена по одной паре проводов используется метод эхо-компенсации. Этот метод предполагает вычитание передаваемого сигнала из принимаемого, определяя тем самым истинную форму входного сигнала. Если на приведенном рисунке 2.1.5 Zвх равно волновому сопротивлению линии, то выходной сигнал передатчика не будет влиять на работу приемника. Здесь предполагается, что выходное сопротивление передатчика много меньше z= zлинии. Учитывая вариации ослабления сигнала, схема эхо-компенсации должна уметь работать в очень широком динамическом диапазоне амплитуд, сохраняя удовлетворительную линейность. Это обстоятельство, а также зависимость zлинии от частоты, приводит к заметному усложнению схем эхо-компенсации (Рис. 2.1.6). Системы эхо-компенсации весьма чувствительны к временному разбросу срабатывания пороговых схем, так как это приводит к фазовому сдвигу вычитаемых друг из друга сигналов.
Рис. 2.1.6. Схема эхо-компенсации с адаптивным фильтром
На рис. 2.1. 7 показана зависимость скорости пропускания от сопротивления петли передающей линии для разных схем кодирования сигнала (пунктирной линией отображен вариант четырехуровневого кодирования). Те, кто работал с выделенными линиями, усвоили эту зависимость на практике. Если сопротивление линии более 1,5 кОм вы скоро будете знать дежурных вашей телефонной станции по имени, узнаете, что такое грозовые вставки и что они имеют привычку окисляться.
Рис. 2.1.7. Зависимость максимальной скорости передачи данных от сопротивления петли передающей линии
Различные методы модуляции приводят к разным уровням перекрестных наводок, и, как следствие, могут обеспечить разные скорости пропускания сигналов. Так применение линейной эквилизации при амплитудной модуляции дает улучшение пропускной способности примерно в 5 раз. Из рисунка 2.1.8 видно, что переход от линейного выравнивания к эквилизации с обратной связью позволяет добиться улучшения почти в 1,5 раза. Многоуровневый метод кодирования увеличивает скорость пропускания еще на 30%. Следует, правда, иметь в виду, что многоуровневый метод кодирования характеризуется большим уровнем импульсных помех и, следовательно, ошибок.
Рис. 2.1.8. Минимальное отношение сигнал-шум при скорости передачи ~150кбит/с
На рис. 2.1.8 показана зависимость отношения сигнал-шум от сопротивления петли для разных схем передающего канала. Пунктиром проведены зависимости для случая четырехуровневого кодирования. Кривые 1 соответствует случаю амплитудной модуляции с линейным выравниванием, а кривые 2 - варианту эквилизации с обратной связью.
Ping и Traceroute
4.5.1 Ping и Traceroute
Семенов Ю.А. (ГНЦ ИТЭФ)
При работе в Интернет время от времени возникают ситуации, когда нужно определить, работоспособен ли тот или иной канал или узел, а в случае работы с динамическими протоколами маршрутизации выяснить, по какому из каналов вы в данный момент работаете. Используется эта процедура и для оценки вероятности потери пакетов в заданных сегментах сети или каналах. Для решения этих задач удобна программа Ping.
Ping - это процедура, которая базируется на ICMP- и UDP-протоколах пересылки дейтограмм и служит для трассировки маршрутов и проверки работоспособности каналов и узлов (в некоторых программных пакетах эта команда имеет имена trace, hopcheck, tracert или traceroute). Для решения поставленной задачи PING использует отклики протокола ICMP. Применяется PING и при отладке сетевых продуктов. Трассировка может выполняться, например, посредством команды ping -q (пакет PCTCP). При выполнении этой команды ЭВМ сообщит вам Internet адреса всех промежуточных узлов, их имена и время распространения отклика от указанного вами узла. Следует иметь в виду, что трассировка осуществляется непосредственно с помощью IP-протокола (опция записи адресов промежуточных узлов). Ниже приведен пример использования команды Ping. Если вы просто напечатаете команду ping (пакет PCTCP), то ЭВМ выдаст на экран справочную таблицу по использованию этой команды:
Usage:
ping [-options] host
options:
ping -q mcmurdo-gw.mcmurdo.gov > route.txt
Содержимое файла route.txt будет иметь вид:
| hop 1: | 193.124.224.190 | ??? | имя для GW ИТЭФ пока не придумано |
| hop 2: | 193.124.137.13 | MSU-Tower.Moscow.RU.Radio-MSU.net | Вперед, в космос |
| hop 3: | 193.124.137.9 | NPI-MSU.Moscow.RU.Radio-MSU.net | Через спутник "Радуга" |
| hop 4: | 193.124.137.6 | DESY.Hamburg.DE.Radio-MSU.net | пакеты совершили мягкую посадку в Гамбурге, ДЕЗИ |
| hop 5: | 188.1.133.56 | dante.WiN-IP.DFN.DE | |
| hop 6: | 193.172.4.12 | duesseldorf2.empb.net | |
| hop 7: | 193.172.4.8 | amsterdam6.empb.net | |
| hop 8: | 193.172.12.6 | Amsterdam1.dante.net | Пересекаем Атлантический океан |
| hop 9: | 194.41.0.42 | New-York1.dante.net | вступили на землю США |
| hop 10: | 192.103.63.5 | en-0.cnss35.New-York.t3.ans.net | |
| hop 11: | 140.222.32.222 | mf-0.cnss32.New-York.t3.ans.net | |
| hop 12: | 140.222.56.2 | t3-1.cnss56.Washington-DC.t3.ans.net | |
| hop 13: | 140.222.145.1 | t3-0.enss145.t3.ans.net | |
| hop 14: | 192.203.229.243 | SURA2.NSN.NASA.GOV | Снова в космос |
| hop 15: | 128.161.166.1 | GSFC8.NSN.NASA.GOV | но теперь через американский |
| hop 16: | 128.161.232.1 | GSFC12.NSN.NASA.GOV | спутник |
| hop 17: | 128.161.1.1 | ARC1NEW.NSN.NASA.GOV | |
| hop 18: | 192.203.230.2 | ARC1.NSN.NASA.GOV | |
| hop 19: | 192.100.12.2 | ARC2.NSN.NASA.GOV | |
| hop 20: | 128.161.115.2 | MCMURDO.NSN.NASA.GOV | Оденьте шапку, мы в Антарктиде! |
| Target | 157.132.100.1 | reached on hop 21 | round-trip time 1370 ms |
/p> Фантастика, мы пересекли туда и обратно Европу, два океана и США с востока на запад, побывали в Антарктиде и все это менее чем за полторы секунды.
Ping позволяет не только проверить работоспособность канала, но измерить ряд его характеристик, включая надежность (например, версия ping для SUN):
PING -s cernvm.cern.ch 100 64 (пакеты по 100 байт посылаются 64 раза)
108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq=0. time=606. Ms
.............. (результаты пересылки пакетов с номерами 1-61 опущены)
108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq=62. time=667. Ms
108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq=63. time=628. Ms
---- PING Statistics ----
64 packets transmitted, 63 packets received, 1% packet loss (процент потерянных пакетов)
round-trip (ms) min/avg/max = 600/626/702
Для получения большей точности следует послать большее число пакетов. В последней строке приведены результаты измерения RTT, где представлены минимальное/среднее/максимальное значения.
Наибольшее число модификаций имеет BSD-версия ping, если на вашей ЭВМ нет этой удобной программы, можно воспользоваться общедоступной версией по адресу:
ftp.uu.net /unix/bsd-sources/sbin/ping (см. также приложения).
Сходную информацию позволяет получить и программа traceroute (использует непосредственно IP-пакеты):
traceroute -n cernvm.cern.ch
traceroute to crnvma.cern.ch (128.141.2.4) 30 hops max, 40 byte packets
1 193.124.224.50 3 ms 2 ms 2 ms
2 194.85.112.130 3 ms 3 ms 3 ms
3 194.67.80.5 4 ms 3 ms 3 ms
4 193.124.137.6 534 ms 534 ms 534 ms
5 188.1.56.5 545 ms 545 ms 546 ms
6 193.172.4.12 558 ms (ttl=59!) 549 ms (ttl=59!) 548 ms (ttl=59!)
7 193.172.4.30 580 ms (ttl=58!) 581 ms (ttl=58!) 581 ms (ttl=58!)
8 193.172.24.10 586 ms 585 ms 597 ms
9 192.65.185.1 593 ms 587 ms 598 ms
10 128.141.2.4 628 ms 602 ms 619 ms
При написании программ, использующих протокол ICMP, полезно воспользоваться отладочной опцией PING, которая позволяет получить на экране шестнадцатеричный образ посылаемого и получаемого пакетов:
| ping -d# 300 ns.itep.ru | (версия PCTCP, запрос отклика серверу имен, число байт, подлежащих выдаче, равно 300) |
Dump of outgoing packet
Version = 4 IP header length = 5 Precedence = Routine
Type of Service = Normal
Total length = 284 Protocol = 1 TTL = 64
45 00 01 1C 00 02 00 00 40 01 71 29 C0 94 A6 81 C1 7C E0 23 IP-заголовок
08 00 8D BD E9 03 00 01 ... ICMP-заголовок
host responding, time = 60 ms
Выдачи ради экономии места сильно сокращены. Тексты пакетов начинаются с кодов IP-версии (=4) и длины заголовка (=5), далее следует байт TOS=0, два байта длины пакета (01 1С) и т.д. в соответствии с требованиями IP-протокола.
ping -d 300 ns.itep.ru
(команда получения текста пакета-отклика на запрос)
host responding, time = 25 ms
Dump of incoming packet
Version = 4 IP header length = 5 Precedence = Routine
Type of service = Normal
Total length = 284 Protocol = 1 TTL = 254
45 00 01 1C EE 29 00 00 FE 01 C5 00 C1 7C E0 23 C0 94 A6 81
00 00 93 BD EB 03 00 01 ..............
В принципе, процедуру Ping и Traceroute можно реализовать и с привлечением протоколов UDP и TCP. Рассмотрим следующую модель реализации Traceroute :
Посылаем последовательно по адресу IP(URL) IP-пакеты со значением TTL=1, 2,... и т.д. Если до больше одного шага, соответствующий маршрутизатор, размещенный по пути следования к адресату, уничтожит посланный пакет и вернет ICMP-сообщение: Time Exceeded (тип ICMP-сообщения=11), указав при этом IP-адрес узла, где это произошло. Послав запрос типа get_name_by_address для присланного IP, можно получить имя узла, откуда пришло данное уведомление. Отсутствие сообщения Time Exceeded (например, после трех попыток) будет говорить о достижении -адресата. В результате такой последовательности посылок будет получена исчерпывающая информация о пути до указанной цели.
Для данной методики реализации traceroute не существенно, какой протокол использовать, UDP, ICMP или TCP.
В некоторых небольших узлах Интернет
4.4.14.2 Почтовый протокол POP3
Семенов Ю.А. (ГНЦ ИТЭФ)
В некоторых небольших узлах Интернет бывает непрактично поддерживать систему передачи сообщений (MTS - Message Transport System). Рабочая станция может не иметь достаточных ресурсов для обеспечения непрерывной работы SMTP-сервера [RFC-821]. Для “домашних ЭВМ” слишком дорого поддерживать связь с Интернет круглые сутки.
Но доступ к электронной почте необходим как для таких малых узлов, так и индивидуальных ЭВМ. Для решения этой проблемы разработан протокол POP3 (Post Office Protocol - Version 3, STD: 53. M. Rose, RFC-1939). Этот протокол обеспечивает доступ узла к базовому почтовому серверу.
POP3 не ставит целью предоставление широкого списка манипуляций с почтой, он лишь получает и стирает почтовые сообщения. Более продвинутый и сложный протокол IMAP4 обсуждается в RFC-2060 (порт 143). Об аутентификации в POP3 можно прочесть в документе RFC-1734.
В дальнейшем ЭВМ-клиентом будет называться машина, пользующаяся услугами POP3, а ЭВМ-сервером – сторона, предлагающая услуги POP3.
Когда пользователь ЭВМ-клиента хочет послать сообщение, он устанавливает SMTP связь с почтовым сервером непосредственно и посылает все, что нужно через него. При этом ЭВМ POP3-сервер не обязательно является почтовым сервером.
В исходный момент ЭВМ POP3-сервер прослушивает TCP-порт 110. Если ЭВМ-клиент хочет воспользоваться услугами POP3-сервера, то устанавливает с ним TCP связь. По установлении связи POP3-сервер посылает клиенту уведомление (например, +OK POP3 server ready) и сессия переходит в фазу авторизации (см. также RFC-1734, -1957). После этого может производиться обмен командами и откликами.
Команды POP3 состоят из ключевых слов (3-4 символа), за которыми могут следовать аргументы. Каждая команда завершается парой символов CRLF. Как ключевые слова, так и аргументы могут содержать только печатаемые ASCII-символы. В качестве разделителя используются символы пробела. Каждый аргумент может содержать до 40 символов.
Сигнал отклика в POP3 содержит индикатор состояния и ключевое слово, за которым может следовать дополнительная информация. Отклик также завершается кодовой последовательностью CRLF. Длина отклика не превышает 512 символов, включая CRLF. Существует два индикатора состояния: положительный - "+OK" и отрицательный "-ERR" (все символы прописные).
Отклики на некоторые команды могут содержать несколько строк. В этом случае последняя строка содержит код завершения 046 ("."), за которым следует CRLF.
На практике многострочные отклики для исключения имитации завершаются последовательностью CRLF.CRLF.
В процессе авторизации клиент должен представить себя серверу, передав имя и пароль (возможен вариант посылки команды APOP). Если авторизация успешно завершена, сессия переходит в состояние транзакции (TRANSACTION). При получении от клиента команды QUIT сессия переходит в состояние UPDATE, при этом все ресурсы освобождаются и TCP связь разрывается.
На синтаксически неузнанные и неверные команды, сервер реагирует, посылая отрицательный индикатор состояния.
POP3 сервер может быть снабжен таймером пассивного состояния (10 мин.), который осуществляет автоматическое прерывание сессии. Приход любой команды со стороны клиента сбрасывает этот таймер в нуль.
Сервер нумерует все передаваемые сообщения из своего почтового ящика и определяет их длину. Положительный отклик начинается с +OK, за ним следует пробел, номер сообщения, еще один пробел и длина сообщения в октетах. Завершается отклик последовательностью CRLF. Переданные сообщения удаляются из почтового ящика сервера. Все сообщения, передаваемые во время сессии POP3 должны следовать рекомендациям формата Интернет сообщений [RFC822].
В состоянии транзакции клиент может посылать серверу последовательность POP3 команд, на каждую из которых сервер должен послать отклик. Далее следует краткое описание команд, используемых в состоянии транзакция.
LIST [сообщение]
Аргументы: номер сообщения (опционно), который не может относиться к сообщению, помеченному как удаленное. Команда может быть выдана только в режиме TRANSACTION. При наличии аргумента сервер выдает положительный отклик, содержащий информационную строку сообщения. Такая строка называется скэн-листингом сообщения (scan listing). scan listing состоит из номера сообщения, за которым следует пробел и число октетов в сообщении. Сообщения, помеченные как удаленные, не пересылаются. Примером отрицательного отклика может служить: -ERR no such message.
Примеры использования команды LIST:
Клиент выдает команду: LIST
Сервер откликается: +OK 2 messages (320 octets)
Сервер: 1 120
Сервер: 2 200
Сервер: .
...
Клиент: LIST 2
Сервер: +OK 2 200
...
К: LIST 3
С: - ERR no such message, only 2 messages in maildrop
Здесь и далее символом К обозначается клиент, а символом С - сервер.
STAT - аргументов не использует, возможный отклик +OK nn mm, где nn – номер сообщения, а mm – его длина в байтах. Пример использования:
К: STAT
С: +OK 2 320
QUIT - аргументов не использует, возможный отклик +OK.
Сервер POP3 удаляет все сообщения, помеченные как удаленные из почтового ящика, посылает соответствующий отклик и разрывает TCP связь. Пример:
К: QUIT
С: +OK dewey POP3 server signing off.
RETR msg (msg – номер сообщения)
Если POP3-сервер выдал положительный отклик, то за начальным +OK следует сообщение с номером, указанным в аргументе. Отрицательный отклик имеет вид -ERR no such message.
Пример использования команды:
К: RETR 1
С: +OK 120 octets
С:
С: .
DELE msg (msg – номер сообщения)
Сервер POP3 помечает сообщение как удаленное. Любая ссылка на это сообщение в будущем вызовет ошибку. При этом само сообщение не удаляется пока сессия не войдет в режим UPDATE.
Пример использования команды:
К: DELE 1
С: +OK message 1 deleted
...
К: DELE 2
С: -ERR message 2 already deleted
NOOP (не использует каких-либо аргументов). При реализации этой команды сервер не делает ничего, лишь посылает положительный отклик.
RSET (не использует каких-либо аргументов)
Если какие-либо сообщения помечены как удаленные, сервер POP3 удаляет эту пометку и возвращает положительный отклик. Например:
К: RSET
С: +OK maildrop has 2 messages (320 octets)
Если сессия завершается не по команде клиента, то перехода в состояние UPDATE не производится, а сообщения не удаляются из почтового ящика. Далее следует описание команд, используемых в состоянии UPDATE.
Ряд команд не входят в перечень обязательных (являются опционными).
TOP msg n, где msg – номер сообщения, а n – число строк (используется только в режиме TRANSACTION).
При положительном отклике на команду TOP сервер посылает заголовки сообщений и вслед за ними n строк их текста. Если n больше числа строк в сообщении, посылается все сообщение.
UIDL [msg], где msg – номер сообщения является опционным (Unique-ID Listing).
Если сервер выдаст положительный отклик, будет выдана строка, содержащая информацию о данном сообщении. Эта строка называется уникальным идентификатором сообщения ("unique-id listing"). При отсутствии аргумента аналогичная информация выдается для каждого из сообщений в почтовом ящике. Уникальный идентификатор сообщения состоит из 1-70 символов в диапазоне от 0x21 до 0x7E. Сообщения в почтовом ящике должны характеризоваться различными идентификаторами. Пример использования команды:
К: UIDL
С: +OK
С: 1 whqtswO00WBw418f9t5JxYwZ
С: 2 QhdPYR:00WBw1Ph7x7
USER name, где name – характеризует почтовый ящик сервера.
Команда используется на фазе авторизации или после неудачного завершения команд USER или PASS. При авторизации клиент должен сначала послать команду USER и лишь после получения положительного отклика команду PASS. Команда может вызвать следующие отклики:
+OK name is a valid mailbox
-ERR never heard of mailbox name
Примеры использования команды USER:
К: USER frated
С: -ERR sorry, no mailbox for frated here
...
К: USER mrose
С: +OK mrose is a real hoopy frood
PASS string (string – пароль для доступа к почтовому серверу)
Команда работает в режиме авторизации сразу после команды USER. Когда клиент выдает команду PASS, сервер использует аргументы команд USER и PASS для определения доступа клиента к почтовому ящику. На команду PASS возможны следующие отклики:
+OK maildrop locked and ready
-ERR invalid password
-ERR unable to lock maildrop
Пример диалога при использовании команды PASS:
К: USER mrose
С: +OK mrose is a real hoopy frood
К: PASS secret
С: -ERR maildrop already locked
...
К: USER mrose
С: +OK mrose is a real hoopy frood
К: PASS secret
С: +OK mrose's maildrop has 2 messages (320 octets)
APOP name digest, где name – идентификатор почтового ящика, а digest – дайджест сообщения – MD5 (RFC-1828). Команда используется только на стадии авторизации.
Обычно любая сессия начинается с обмена USER/PASS. Но так как в некоторых случаях подключения к серверу POP3 может осуществляться достаточно часто, возрастает риск перехвата пароля. Альтернативным методом авторизации является использование команды APOP. Сервер, который поддерживает применение команды APOP, добавляет временную метку в свое стартовое уведомление. Синтаксис временной метки соответствует формату идентификаторов сообщений, описанному в [RFC822] и должны быть уникальными для всех заголовков уведомлений. Так для UNIX-приложений синтаксис временной метки должен иметь вид:
где `process-ID' представляет собой десятичное значение PID процесса, clock – десятичное показание системных часов, а hostname – полное имя домена, где размещен сервер POP3.
Клиент POP3 фиксирует временную метку и выдает команду APOP. Параметр `name' семантически идентичен параметру `name' команды USER. Параметр `digest' вычисляется с использованием алгоритма MD5 [RFC1321] для строки, состоящей из временной метки (включая угловые скобки) за которой следует строка пароля, которая известна только клиенту и серверу. Параметр `digest' содержит 16 октетов, которые пересылаются в шестнадцатеричном формате с использованием строчных ASCII символов. Сервер, получив команду APOP, проверяет принятый дайджест и если он корректен, посылает положительный отклик клиенту. Сессия при этом переходит в состояние транзакции. В противном случае посылается отрицательный отклик и состояние сессии не изменяется. С целью обеспечения безопасности для каждого конкретного пользователя и сервера должен использоваться либо метод доступа USER/PASS, либо APOP, но не в коем случае оба метода попеременно.
Сервер перед закрытием канала по команде QUIT должен удалить из почтового ящика все сообщения, которые были перенесены с помощью команд RETR.
Предполагается, что все сообщения, передаваемые в ходе сессии POP3, имеют текстовый формат Интернет в соответствии с документом [RFC822].
Поиск узлов и людей
4.5.8 Поиск узлов и людей
Семенов Ю.А. (ГНЦ ИТЭФ)
Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы
4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы
Семенов Ю.А. (ГНЦ ИТЭФ)
На физическом уровне пакет представляет собой цуг импульсов, распространяющихся по коаксиальному кабелю, скрученной паре или оптическому волокну. За счет дисперсии, частичным отражениям от точек подключения и поглощению в среде импульсы в пакете "расплываются" и искажаются (ухудшается отношение сигнал/шум), это является одной из причин ограничения длин кабельных сегментов. Для преодоления этих ограничений вводятся сетевые повторители (repeater). Повторитель воспринимает входные импульсы, удаляет шумовые сигналы и передает вновь сформированные пакеты в следующий кабельный сегмент или сегменты. Никакого редактирования или анализа поступающих данных не производится. Задержка сигнала повторителем не должна превышать 7,5 тактов (750нсек для обычного Ethernet). Повторители могут иметь коаксиальные входы/выходы, AUI-разъемы для подключения трансиверов или других аналогичных устройств, или каналы для работы со скрученными парами.
Рис. 4.1.1.4.1 Схема сетевого повторителя
Все входы/выходы повторителя с точки зрения пакетов эквивалентны. Если повторитель многовходовый, то пакет пришедший по любому из входов будет ретранслирован на все остальные входы/выходы повторителя. Чем больше кабельных сегментов объединено повторителями, тем больше загрузка всех сегментов. При объединении нескольких сегментов с помощью повторителя загрузка каждого из них становится равной сумме всех загрузок до объединения. Это справедливо как для коаксиальных кабельных сегментов, так и для повторителей, работающих со скрученными парами (хабы - концентраторы). Некоторые повторители контролируют наличие связи между портом и узлом (link status), регистрируют коллизии и затянувшиеся передачи (jabber – узел осуществляет передачу дольше, чем это предусмотрено протоколом), выполняют согласование типа соединения (autonegotiation). В этом случае они обычно снабжены SNMP-поддержкой.
Для преодоления этого нежелательного явления используются сетевые мосты или переключатели. Мост соединяет два сегмента сети, при инициализации он изучает списки адресов устройств, подсоединенных к каждому из сегментов. В дальнейшем мост записывает в свою память эти списки и пропускает из сегмента в сегмент лишь транзитные пакеты. Существуют мосты, которые оперируют с физическими и с IP-адресами (cм. стандарт IEEE 802.1d).
Рис. 4.1.1.4.2. Схема сетевого моста
Мост является активным устройством, которое способно адаптироваться к изменениям в окружающей сетевой среде. При этом пакеты, отправленные из сегмента А и адресованные устройству, которое подключено к этому же сегменту, никогда не попадут в сегмент Б и наоборот. Через мост проходят лишь пакета, отправленные из сети А в Б или из Б в А.
Функцию моста с определенными скоростными ограничениями может выполнять и обычная ЭВМ, имеющая два сетевых интерфейса и соответствующее программное обеспечение. Мосты при разумном перераспределении серверов и рабочих станций по сетевым сегментам позволяют выровнять и даже эффективно снизить среднюю сетевую загрузку. Когда на один из входов моста приходит пакет, производится сравнение адреса получателя с содержимым внутренней базы данных. Если адрес в базе данных отсутствует, мост посылает широковещательный запрос в порт, противоположный тому, откуда получен данный пакет с целью выяснения местоположения адресата. Понятно, что появление в субсетях a и Б двух объектов с идентичными адресами ни к чему хорошему не приведет. При поступлении отклика вносится соответствующая запись в базу данных. Параллельно анализируется и адрес отправителя и, если этот адрес в базе данных отсутствует, производится его запись в банк адресов соответствующего порта. В базу данных записывается также время записи адреса в базу данных. Содержимое базы данных периодически обновляется. К любой подсети может вести несколько путей, но для нормальной работы мостов и переключателей все пути кроме одного должны быть заблокированы. Функциональная схема работы моста показана на рис. 4.1.1.4.3. Сети, между которыми включается мост, не обязательно должны работать согласно идентичным протоколам. Возможны мосты между Ethernet и Token Ring или между Ethernet и ATM.
Рис. 4.1.1.4.3 Блок-схема работы сетевого моста
Мост, имеющий более двух портов, называется переключателем. Первый переключатель был разработан фирмой Калпане в 1991 году. Иногда переключатели называются маршрутизаторами, тем более что некоторые из них поддерживают внутренние протоколы маршрутизации (например, RIP). Переключатели имеют внутреннюю параллельную магистраль очень высокого быстродействия (от десятков мегабайт до гигабайт в сек.). Эта магистраль позволяет переключателю совместить преимущества повторителя (быстродействие) и моста (разделение информационных потоков) в одном устройстве. Схемы реализации переключателей варьируются значительно, каких-либо единых стандартов не существует. Алгоритм работы с адресами здесь тот же, что и в случае мостов. На рис. 4.1.1.4.4 приведена схема 8-входового переключателя. В переключателе все входы идентичны, но внешняя информация, записанная в их память, делает входы неэквивалентными. Определенные проблемы возникают, когда к одному из входов переключателя подключен сервер, с которым работают пользователи подключенные к остальным входам. Если все ЭВМ, подключенные к переключателю, одновременно попытаются обратиться к серверу, переключатель перегрузится и все каналы будут на некоторое время блокированы (будет послан сигнал перегрузки – jam). При данной схеме вероятность таких событий значительна, так как несколько каналов с пропускной способностью 10 Мбит/с работают на один общий канал с той же полосой пропускания. Для преодоления проблем этого рода следует распределять нагрузки между портами переключателя равномерно, а также подключать серверы через полнодуплексные каналы. Полнодуплексные каналы полезны и для соединения переключателей между собой. Современные переключатели имеют много различных возможностей – SNMP поддержка, автоматическая настройка быстродействия и определения типа соединения (дуплексная/полудуплексная). Имеется возможность внешней загрузки программы работа переключателя. Способы проверки производительности переключателей описаны в документах RFC-1242 и RFC-1944 (тесты Бреднера, см. www.wiley.com/compbooks/fastethernet и www.tolly.com).
Рис. 4.1.1.4.4. Схема 8-входового сетевого переключателя
Существуют переключатели, работающие в режиме “на пролет” (cut through). Здесь первые биты пакета поступают на выход переключателя, когда последующие еще только приходят на вход. Задержка в этом случае минимальна, но переключатель пропускает через себя пакеты, поврежденные в результате столкновений. Альтернативой такому режиму является передача через буферную память (схема передачи SAF – Store And Forward). Поврежденные пакеты в этом режиме отбрасываются, но задержка заметно возрастает. Кроме того, буферная память должна иметься на всех входах (или общая многопортовая). При проектировании сетей следует иметь в виду, что переключатели превосходят маршрутизаторы по соотношению производительность/цена.
При проектировании локальной сети следует учитывать то обстоятельство, что узлы с самым напряженным трафиком должны располагаться как можно ближе к повторителю (мосту или переключателю). В этом случае среднее число коллизий в единицу времени будет ниже. По этой причине сервер должен располагаться как можно ближе к повторителю или другому сетевому устройству (см. рис. 4.1.1.4.6).
Схема внутренних связей переключателя может отличаться от приведенной на рис. 4.1.1.4.4 и иметь конфигурацию, показанную на рис. 4.1.1.4.5. Привлекательность такой схемы заключается в возможности реализации обмена по двум непересекающимся направлениям одновременно (См. LAN. Журнал сетевых решений, май 1998, том 4, N5, стр 21. Дмитрий Ганжа). От разделяемых к коммутируемым сетям). При этом эффективная пропускная способность многопортового переключателя может в несколько раз превосходить полосу пропускания сети, например, 10 Мбит/с.
Рис. 4.1.1.4.5. Вариант схемы внутренних связей переключателя.
Рис. 4.1.1.4.6 Схема подключения сервера к переключателю
При использовании в сети большого числа мостов и/или переключателей может сформироваться топология связей, когда от одного сегмента к другому пакет может попасть более чем одним путем (см. рис. 4.1.1.4.7). Приведенная на рисунке схема неработоспособна и некоторые связи должны быть ликвидированы. В данном примере проблема может быть решена удалением мостов BR-2 и BR-3 или разрывом связей, помеченных символом “X”.
Проблему ликвидации связей, способных привести к зацикливанию, решает протокол STP (Spanning Tree Protocol; алгоритм предложен Пёлманом в 1992 году), который автоматически блокирует некоторые соединения, а в случае недоступности основного пути открывает эти заблокированные соединения, обеспечивая высокую надежность сети. STP является частью протокола мостов IEEE 802.1d.
При использовании протокола STP каждой связи присваивается при конфигурации определенный вес (чем меньше, тем выше приоритет). Мосты периодически рассылают специальные сообщения (BPDU - Bridge Protocol Data Unit), которые содержат коды их уникальных идентификаторов, присвоенные им при изготовлении. Мост или переключатель с наименьшим значением такого кода становится корневым ("корень дерева"). Затем выявляется наикратчайшее расстояние от корневого моста/переключателя до любого другого моста в сети. Граф, описывающий дерево наикратчайших связей, и является "расширяющимся деревом". Такое дерево включает все узлы сети, но необязательно все мосты/переключатели. Этот алгоритм функционирует постоянно, отслеживая все топологические изменения.
Современные мосты позволяют создавать виртуальные субсети (VLAN), увеличивающие сетевую безопасность. VLAN позволяет ограничить зону распространения широковещательных пакетов, улучшая эксплуатационные характеристики сети в целом.
Рис. 4.1.1.4.7. Пример реализации алгоритма "расширяющееся дерево"
Некоторые современные мосты используют так называемую маршрутизацию отправителя (source routing). Такая маршрутизация предполагает, что отправитель знает, находится ли адресат в пределах локальной сети и может оптимально определить путь доставки. При посылке кадра другой сети отправитель устанавливает старший бит своего адреса равным единице. Одновременно в заголовке кадра прописывается весь маршрут. Каждой сети присваивается 12-битовый идентификатор, а каждому мосту ставится в соответствие 4-битовый код, уникальный в контексте данной сети. Это означает, что мосты в пределах одной сети должны иметь разные идентификаторы, но их коды могут совпадать, если они находятся в разных сетях. Мост рассматривает только кадры с единицей в старшем бите адреса места назначения. Для этих кадров просматриваются коды сети в списке, записанном в заголовке. Если в списке содержится код, совпадающий с тем, который характеризует сеть, где находится мост, кадр переадресуется в эту сеть. Реализация алгоритма может осуществляться программно или аппаратно. Если путь до места назначения неизвестен, отправитель генерирует специальный пакет, посылаемый широковещательно (discovery frame) и достигающий всех мостов и всех субсетей. Когда приходит отклик от адресата, мосты записывают его идентификатор, а первичный отправитель фиксируют маршрут до адресата. Данный алгоритм достаточно прост, но сопряжен с лавинным размножением "исследовательских" пакетов особенно в случае, когда смежные сети соединяются через несколько мостов/переключателей.
Маршрутизатор отличается от переключателя тем, что поддерживает хотя бы один протокол маршрутизации. Существуют внутренние и внешние протоколы маршрутизации. Если маршрутизатор осуществляет связь данной автономной системы с другими автономными системами, его называют пограничным (border). Маршрутизатор же, который имеет только один внешний канал связи, в литературе часто называют gateway (входной порт сети). Любой маршрутизатор может поддерживать в любой момент только один внутренний и один внешний протокол маршрутизации, выбор этих протоколов осуществляет администратор сети из имеющегося списка. Маршрутизаторы представляют собой наиболее сложные сетевые устройства. Главным достоинством маршрутизаторов в локальной сети является ограничение влияния потоков широковещательных сообщений.
В последнее время заметное распространение получил гибрид маршрутизатора и моста – brouter. Некоторые протоколы (например, NetBIOS) не допускают маршрутизации. Когда необходимо использовать такие протоколы совместно с TCP/IP, необходим brouter. Широко используются такие приборы в сетях Token Ring.
Особый класс образуют мультиплексоры/демультиплексоры, которые используют собственные протоколы и служат для предоставления общего канала большему числу потребителей. Эти устройства широко используются при построении сетей типа Интранет (корпоративные сети, где субсети разных филиалов разнесены на большие расстояния). Такие сети строятся на базе специальных выделенных каналов, а мультиплексоры позволяют использовать эти каналы для предоставления комплексных услуг: телефонной связи, передачи факсов и цифровой информации, экономя значительные средства.
Если перед вами стоит задача создания локальной сети с выходом в Интернет, вам нужно последовательно решить ряд проблем помимо финансовых. Должны быть сформулированы задачи, ради которых эта сеть создается, определена топология сети, число сегментов и характер их связей, число ЭВМ-участников, определен сервис-провайдер, или провайдеры, если вам нужно обеспечить более высокую надежность и живучесть сети. Вам надо оценить требуемую загрузку сегментов сети и внешних каналов связи, выбрать программную среду. После этого вы можете приступить к составлению списка необходимого оборудования и программного обеспечения. Если ваша сеть является оконечной и она имеет только один внешний канал связи, вам не нужен маршрутизатор и вы можете ограничиться ЭВМ-портом (gateway), которая должна иметь необходимый интерфейс. Внешним каналом может стать коммутируемая телефонная сеть, выделенная телефонная линия, оптоволоконный кабель или радиорелейный канал. Во всех перечисленных случаях вам будет необходим соответствующий модем.
nThis file was not retrieved
Предисловие
Семенов Ю.А. (ГНЦ ИТЭФ)
Telecommunication technologies - телекоммуникационные технологии (v2.1)
Данный сервер частично создан на средства, выделенные по проектам РФФИ (99-07-90102 и 01-07-90069). В основу материалов легли тексты книг автора "Протоколы и ресурсы Интернет" (Радио и связь, М. 1996) и "Сети Интернет. Архитектура и протоколы" (Сиринъ, М. 1998), а также "Протоколы Интернет. Энциклопедия" ("Горячая линия - Телеком", М. 2001), которые базировались на двух курсах, читаемых студентам кафедры "Телекоммуникационные сети и системы" МФТИ (факультет ФПФЭ) - "Каналы и сети передачи данных", "Протоколы Интернет".
В сумме эти книги содержат около 1850 страниц, а на данном сервере размещается более 2600 стандартных книжных страниц (формат A4, times-12, следует заметить, что содержимое книг частично перекрывается). Причин здесь несколько.
Во-первых, ограниченность времени и жанр лекций не позволяют разместить полные описания протоколов (конспективность здесь неизбежна) и представить необходимые справочные материалы. Сервер, включая рисунки и формулы, содержит более 1000 файлов.
Во-вторых, данное направление науки и технологии развивается стремительно и отследить прогресс в этой отрасли с использованием техники книжных издательств практически невозможно (первая книга готовилась к печати с уровня машинных файлов около года, вторая - 4 месяца). Автор решил попытаться решить эту проблему методами современных сетевых технологий. Ускорение, которое достижимо в этом случае очевидно. Но у этого метода есть и несомненные недостатки - в книжном издательстве за ошибки отвечает редактор и корректор, а здесь автору это свалить не на кого. Практически невозможно избежать и некорректности сетевых ссылок, в Интернет все меняется слишком быстро. То что ещё вчера было доступно, сегодня может более не существовать. Зато вместо этого появляется несколько новых, чаще всего более емких ссылок. По этой причине я заранее прошу извинения за ошибки, содержащиеся в текстах, размещенных на сервере. Эта работа заняла несколько лет, сейчас мне очень трудно обнаружить даже некоторые очевидные описки и ошибки, ведь я вижу не тот текст, что читаете вы, а тот, который я намеревался написать, а это не одно и то же. Буду весьма признателен читателям, обнаружившим любые ошибки и приславшим замечания. Это позволит мало-помалу привести материалы в должный порядок, сделать их более полными (общими силами это будет сделать легче). Надеюсь, что неизбежные ошибки не слишком испортят настроение читателей. Будут приниматься и пожелания по размещению новых материалов. Предполагается размещение новых материалов и других авторов. Окончательное решение по вопросу постановки таких статей будет приниматься мной. Авторские права в таких случаях будут неукоснительно соблюдаться.
Форма сервера позволяет непрерывно дополнять и корректировать материалы. В настоящее время содержимое сервера ориентировано на широкий круг читателей и в силу этого страдает недостаточной строгостью, например, здесь отсутствуют теоретические обоснования многих формул или выбора того или иного сетевого решения. Позднее это может быть устранено путем введения дополнительных глав, посвященных теории телекоммуникаций.
Помимо стандартных гиперссылок каждая из статей содержит в верхней части кнопки управления. <previous> - для перехода к предыдущей статье; <up> - к предыдущему разделу; <down> - к следующему разделу; <next> - для перехода к следующей статье; а также кнопка <index>, которая служит для обращения к оглавлению. Объем статей (в килобайтах) указан с учетом рисунков, хранящихся в виде отдельных файлов. Самая правая клавиша <ПОИСК> осуществляет переход на страницу, где размещена форма, позволяющая выполнить поиск в пределах данного сервера. При этом выдаются ссылки на все статьи (и позиции), где имеются представленные ключевые слова.
Надеюсь, что данный сервер окажется для вас полезным.
В дальнейшем предполагается предложить версию сервера на CD со встроенной поисковой системой. Для студентов и всех желающих создан тренажер для проверки знаний по отдельным разделам (saturn.itep.ru и http://knowtest.itep.ru). Для просмотра сервера желательно использовать версии Netscape communicator v4+ и MS Explorer с версией 5+. Тренажер и многие программы из http:/saturn.itep.ru работают исключительно с MS Explorer.
Для некоммерческих целей читатели могут использовать данные тексты без ограничений. Размещение полных текстов или фрагментов на других серверах без согласия автора не допускается. ©
Данная версия сервера сформирована с использованием базы данных MySQL, куда были помещены все статьи. Дизайн страниц и формирование индексов определяется шаблонами, что облегчает любые изменения. Программы для этого были подготовлены сотрудником ИТЭФ Михаилом Крикуном (admin@ol.ru). Им же была поставлена поисковая система. Сервер размещен на ЭВМ saturn.itep.ru, администратор - Роман Нилов (Roman@itep.ru).
По вопросам приобретения книги "Протоколы Интернет. Энциклопедия" ("Горячая линия - Телеком", Москва, 2001 год) следует обращаться к Занину Евгению Александровичу по телефону 287-49-56 (radios_hl@mtu-net.ru)
Нач. лаб. Института Теоретической и Экспериментальной Физики (semenov@itep.ru)
Семенов Юрий Алексеевич
Представление электрических сигналов в цифровой форме
2.2 Представление электрических сигналов в цифровой форме
Семенов Ю.А. (ГНЦ ИТЭФ)
Высокую надежность. Если шум ниже входного порога, его влияние не ощущается, возможна повторная посылка кода.
Отсутствие зависимости от источника информации (звук, изображение или цифровые данные).
Возможность шифрования, что повышает безопасность передачи.
Независимость от времени. Можно передавать не тогда, когда информация возникла, а когда готов канал.
На рисунке 2.2.1В представлена уже не последовательность импульсов, а последовательность переходов из одного состояния в другое. При этом уровень +V соответствует логической , а -V - логическому . Переключение из состояния в состояние и наоборот (бод) уже не соответствует передаче одного бита.
Рис. 2.2.1 Передача цифровых кодов по передающей линии
На практике число нулей или единиц следующих подряд не лимитировано. По этой причине на принимающей стороне при этом рано или поздно возникает проблема синхронизации временных шкал передатчика и приемника. Для решения этой проблемы существует два метода передачи данных: синхронный и асинхронный. Асинхронный метод используется для относительно низкоскоростных каналов передачи и автономного оборудования. Синхронный метод применяется в скоростных каналах и базируется на пересылке синхронизующего тактового сигнала по отдельному каналу или путем совмещения его с передаваемыми данными. При наличии синхронизации приемника и передатчика можно допустить более длинные последовательности нулей или единиц, что способствует повышению пропускной способности. На рис. 2.2.2 показана схема канала, использующая технику импульсно-кодовой модуляции. Импульсно-кодовая модуляция (ИКМ) была предложена в 30-ые годы 20-го века, но реализована лишь в 1962 году.
Рис. 2.2.2. Система коммуникаций с использованием кодово-импульсной модуляции (pcm)
Шаг квантования в АЦП должен быть много меньше диапазона вариации входного сигнала. Число уровней квантования n выбирается из соображений минимизации искажений сигнала и повышения уровня s/n. При разумных предположениях (биполярность сигнала (+V -V), однородность распределения уровня сигнала в рабочем диапазоне, ошибка квантования не более S/2, где S шаг квантования, и т.д.) [S/N]db = 10 log10(22n) = 6n (N - шум квантования при этом равен S2/12). Это означает, что при 2n уровнях квантования и при условии, что входной сигнал может варьироваться во всем рабочем диапазоне АЦП, отношение сигнал-шум (S/N), связанное с самим процессом квантования, будет равно 6n при n=8 это составит 48 дБ). Отсюда следует известное значение относительного расстояния между уровнями квантования, равное 6 дБ. Звуковой сигнал может иметь динамический диапазон 40 дБ, что создает определенные проблемы, которые преодолеваются путем прямого и обратного логарифмического преобразования (см. рис. 2.4.1).
Типичный кадр данных в асинхронном канале начинается со стартового бита, за которым следует 8 битов данных. Завершается такой кадр одним или двумя стоп-битами. Стартовый бит имеет полярность противоположную пассивному состоянию линии и переводит приемник в активное состояние. Пример передачи такого кадра показан на рис. 2.2.3.
Рис. 2.2.3. Пример передачи кадра в асинхронном режиме
Одним из способов обеспечения надежной синхронизации является применение в приемнике частоты, например, в 8 раз больше частоты следования данных. При этом стробирование данных может производиться примерно в середине сигнала бита (см. рис. 2.2.4).
Рис. 2.2.4. Схема синхронизации и стробирования с 8-кратной тактовой частотой приемника
Начальный и стоп-биты на каждый байт данных снижают пропускную способность канала и по этой причине используются только для низких скоростей обмена. Увеличение же длины блока данных приводит к ужесточению требований к точности синхронизации. При использовании синхронного метода передачи необходимы специальные меры для выделения кадра в общем потоке данных. Для решения этой задачи используется специальная сигнатура. Если такая последовательность встретится внутри кадра, она видоизменяется путем ввода в нее двоичных нулей (bit stuffing). Синхронный приемник нуждается в синхронизирующем сигнале, передаваемом передатчиком. Обычно это реализуется путем введения определенного вида кодирования сигнала, например, биполярного кодирования. В этом случае используется три уровня сигнала: +v соответствует логической 1; -v – логическому нулю, а 0 вольт логическому нулю или единице. Пример такого типа кодирования показан на рис. 2.2.5.
Рис. 2.2.5. Пример биполярного кодирования сигнала (схема RZ – return-to-zero)
Другой разновидностью такого рода кодирования является использование манчестерского кода. В этой схеме логической единице и нулю соответствует не уровни напряжения, а перепады. Так логической единице поставлен в соответствие переход с низкого уровня на высокий, а логическому нулю – с высокого на низкий (схема NRZ – non-return-to-zero). Пример представления сигнала с использованием манчестерского кода показан на рис. 2.2.6.
Рис. 2.2.6. Кодирование сигнала с использованием манчестерского кода.
Манчестерский код достаточно неэффективно использует пропускную способность канала. Оба описанные выше кода требуют удвоения полосы для передачи данных. Этого можно избежать, используя схему цифровой фазировки DPLL - Digital Phase Locked Loop). Эта схема предполагает применение кодирования NRZI (non-return-zero-inverted). Здесь сигнал сначала кодируется с использованием кода NRZ и только затем последовательность преобразуется в NRZI. В процессе такого преобразования логический нуль из NRZ вызывает определенную модификацию исходного кода, в то время как логическая единица не приводит ни к каким вариациям. Здесь создаются условия, при которых количество переходов 0/1 и 1/0 в единицу времени достаточно велико, чтобы обеспечить надежную синхронизацию. Схема NRZI кодирования с использованием DPLL проиллюстрирована на рис. 2.2.7.
Рис. 2.2.7. NRZI-кодирование
Симметричная скрученная пара проводов с волновым сопротивлением 120 Ом обеспечивает пропускную способность 2048 Мбит/с (система кодирования HDB3, длина проводов ~100м), а 100 Ом - 1544 Мбит/с (амплитуда сигналов 3 в, система кодирования B8ZS). Номинальное значение перепада обычно составляет 750 мВ.
Наиболее простая схема передача данных путем представления и с помощью двух уровней напряжения не применяется из-за того, что линия обычно используется для подачи на оконечное (терминальное) оборудование. Проблема может быть решена, если характеризуется 0 вольт (приращение над постоянным уровнем), а попеременно сигналами положительной и отрицательной полярности (AMI - Alternate Mark Inversion). Такая схема создает проблему синхронизации, когда подряд следует большое число нулей. Необходимо, чтобы было достаточное число переходов 0->1 и 1->0 в единицу времени. Существует также схема ADI (Alternate Digit Inversion), где инверсия полярности производится для каждого из передаваемых двоичных разрядов. Но эта схема менее эффективна.
По этой причине система кодирования AMI была модифицирована в HDB3 (High Density Bipolar 3). Цифра 3 указывает на максимально возможное число последовательных нулей в кодовой последовательности. AMI требует, чтобы передавались попеременно сигналами противоположной полярности, так последовательность 11011 должна быть передана как +-0+-. HDB3 заменяет любую группу из 4 нулей последовательностью из 3 нулей, за которой следует нарушение последовательности отображения единиц. Таким образом, последовательность 11000001 будет отображена как +-000-0+ (возможен инверсный вариант, когда символы + заменяются на - и наоборот). Дальнейшего улучшения балансировки сигнала можно достичь, если заменить код, содержащий 4 нуля подряд, последовательностью b00v (b - обычный биполярный сигнал, v - нарушение последовательности). В США используют схему кодировки B8ZS (Bipolar with 8 Zeros Substitution), где 8 нулей кодируются как 00b0vb0v. В 1986 году ansi принял решение о введение схемы кодирования 2B1Q (2 Binary into 1 Quaternary). При этой схеме каждая пара бит преобразуется в четверичные элементы +3 +1 -1 -3. Код синхронизации (SW - Synchronization Word) при этом содержит 9 четверичных элементов, повторяющихся каждые 1.5 мс:
+3 +3 -3 -3 -3 +3 -3 +3 +3 (+3 соответствует +2.5 В)
В Германии используется схема кодировки 4B3T (4 двоичных разряда кодируются в 3 циклических кода).
Двоичная информация передается блоками, обычно зазываемыми кадрами (или пакетами). В рамках системы 2B1Q для передачи 144 кбит/с требуется частота модуляции не менее 72 кбод. На практике для передачи кадров и выполнения функций управления необходимо создать дополнительные виртуальные каналы. Это доводит требуемую частоту модуляции до 80 кбод. Сводные данные по наиболее популярным схемам кодирования приведены в табл. 2.2.1.
Таблица 2.2.1.
B6ZS
B8ZS
| Биты | quats |
Канал |
| 1-18 | 1-9 | isw (кадр 1) |
| sw (кадры 2-8) | ||
| 19-26 | 10-13 | b-канал 1 |
| 27-34 | 14-17 | b-канал 2 |
| 34-36 | 18 | d-канал |
| 37-44 | 19-22 | b |
| 45-52 | 23-26 | b |
| 53-54 | 27 | d |
| 55-62 | 28-31 | b |
| 63-70 | 32-35 | b |
| 71-72 | 36 | d |
| 73-80 | 37-40 | b |
| 81-88 | 41-44 | b |
| 89-90 | 45 | d |
| 91-98 | 46-49 | b |
| 99-106 | 50-53 | b |
| 107-108 | 54 | d |
| 109-116 | 55-58 | b |
| 117-124 | 59-62 | b |
| 125-126 | 63 | d |
quats
Канал
В традиционной телефонной сети для соединения с требуемым клиентом используются аппаратные коммутаторы. Если коммутатор имеет n входов и n выходов, то одновременно можно реализовать не более n связей. Реально это число всегда меньше и клиент слышит в трубке “короткие гудки” сигнала “занято”. В случае комбинирования традиционного коммутатора с m-канальными мультиплексорами пакетов по времени можно осуществить до m*n связей одновременно. При этом становится возможным объединить нескольких клиентов так, что они все одновременно могут говорить друг с другом. Схема такого переключателя каналов показана на рис. 2.2.8.
Рис. 2.2.8. Схема переключателя каналов с мультиплексированием по времени.
Кружочки на пересечениях линий представляют собой ключи, замыкая которые можно соединить i-й входной канал с j-м выходным. На каждой линии может быть только один замкнутый ключ. Такая схема коммутации называется TST (Time-Space-Time). Именно она преобладает сегодня при построении сетей ISDN. Магистральные каналы ISDN строятся в соответствии со стандартом T1.
Такая схема при числе входных и выходных каналов равном N=1000 требует миллиона элементарных переключателей. Можно рассмотреть вариант когда используются коммутаторы с n входами и k выходами. Схема коммутатора с N=16, n=4 и k=2 показана на рис. 2.2.9. Число элементаных переключателей в таком коммутаторе М равно:
M = 2kN + k(N/n)2
Первое слагаемое характеризует число элементарных переключателей во входной и выходной секциях системы, а второе - число элементарных переключателей в k внутренних модулях При N=1000, n=50 и k=10 требуется 24000 элементарных переключателей вместо миллиона (но и число одновременно формируемых каналов становится много меньше 1000).
Рис. 2.2.9. Каскадный переключатель-мультиплексор.
Преобразование, кодировка и передача информации
2 Преобразование, кодировка и передача информации
Семенов Ю.А. (ГНЦ ИТЭФ)
Для передачи информации на большие расстояния в настоящее время используются исключительно электромагнитные волны (акустические волны пригодны лишь для ограниченных расстояний). При этом пересылка может осуществляться по медным проводам, оптоволоконному кабелю или непосредственно, по схеме передатчик-приемник. В последнем случае используются антенны. Для того чтобы антенна была эффективна, ее размеры должны быть сравнимы с длиной передаваемой волны. Чем шире динамический диапазон передаваемых частот, тем труднее сделать антенну, пригодную для решения этой задачи. Именно по этой причине для передачи используются частоты, начиная с многих сотен килогерц и выше (длина волн сотни метров и меньше). Передача сигнала непосредственно по лучу лазера ограничена расстояниями 100-3000м и становится неустойчивой при наличии осадков даже для инфракрасных длин волн. Между тем человек воспринимает акустические колебания в диапазоне 20-12000 Гц и для целей пересылки звука (например, телефония) требуется именно этот диапазон частот. Динамический диапазон частот в этом случае равен 600, а для высококачественного воспроизведения звука он в два раза шире. При решении этой проблемы используется преобразование частот и различные методы модуляции. Так тот же частотный диапазон, лежащий в пределах (100 - 100,012) Мгц, соответствует динамическому диапазону 0,012%, что позволяет сделать компактную антенну и упростить частотное выделение сигнала.
Для преобразования частот используется перемножение сигналов. Пусть мы имеем два синусоидальных сигнала: A1*sin(w1
t) и A2*sin( w2t). Из тригонометрии известно, что:
A1*sin( w1t)*A2*sin( w2
t)=1/2*A1*A2*[sin( w1+w2)t + sin( w1-w2)t]. [1.1]
Это означает, что в результате перемножения вместо двух частот f1=w1/2p
и f2= w2/2p мы имеем две новые частоты (w1+w2)/2p и (w1-w2)/2p
с амплитудой 1/2*A1*A2. Если входной сигнал имеет полосу 0 - fм, то после перемножения с сигналом, имеющим частоту fн (несущая частота), получим сигнал с полосой в интервале от (fн - fм) до (fн+ fм). Это преобразование проиллюстрировано на рис. 2.1. (по вертикальной оси отложена спектральная плотность сигнала f(jw )). На практике это преобразование выполняется с помощью смесителей или гетеродинов, частота fн называется сигналом гетеродина или несущей.
Рис. 2.1. Частотное преобразование
Получение исходного сигнала из преобразованного достигается путем обратного преобразования, которое сводится к умножению полученного сигнала на sin(wнt), где wн = 2 p*fн. При таком обратном преобразовании мы получим сигнал с исходным частотным диапазоном. Помимо этого будет получен сигнал с полосой от (2fн - fм) до (2fн+ fм). Так как fн обычно много больше fм, серьезных проблем это не вызывает - достаточно воспользоваться соответствующим фильтром. Этому методу обратного преобразования присущи некоторые недостатки. Если сигнал fн имеет фазовый сдвиг q
по отношению к тому, что имел сигнал, использованный при прямом преобразовании, то амплитуда выходного сигнала будет пропорциональна cosq. Понятно, что при вариации фазы амплитуда будет меняться, а при q=p/2 станет нулевой. По этой причине должны быть предприняты специальные меры для синхронизации этих сигналов (fн. передатчика и fн приемника).
Соотношение [1.1] используется при реализации амплитудной, частотной или фазовой модуляции. Так в случае амплитудной модуляции при временной вариации A1 (=Авх) будет изменяться и амплитуда выходного сигнала (А2=Aн - амплитуда несущей частоты при этом остается постоянной; w1=w н при этом может также варьироваться). Форма сигнала на выходе такого преобразователя имеет вид: Авых = Ан[1+Авх(t)] sin wнt. Для получения формы исходного сигнала на принимающей стороне используется схема детектора (например, диодного), на выходе которого получается сигнал, пропорциональный модулю огибающей функции входного сигнала. Существуют и другие методы демодуляции амплитудно-модулированного сигнала. Главным недостатком метода амплитудной модуляции является возможность нелинейных искажений из-за перемодуляции (когда амплитуда модулирующего сигнала слишком велика).
При частотной и фазовой модуляции амплитуда передаваемого сигнала остается почти постоянной, что исключает нелинейные искажения, связанные с широким динамическим амплитудным диапазоном. Выходной сигнал для этого вида модуляции имеет вид: Авых = Ан
sin[wнt + q(t)], где q(t) зависит от формы преобразуемого входного сигнала. Часто используется комбинация амплитудной и фазовой модуляции, которая носит название квадратурной модуляции.
Системы передачи данных с амплитудной или частотной модуляцией являются аналоговыми системами и по этой причине весьма чувствительны к шумам на входе приемника. Применение цифровых методов пересылки информации увеличивает вероятность корректной доставки. Если для аналоговой передачи требуется отношение сигнал/шум на уровне 40-60 дБ, то при цифровой передаче достаточно 10-12 дБ. Выбор типа модуляции зависит от стоящей задачи и от характеристик канала (полосы пропускания, ослабления сигнала и т.д.). Частотная модуляция менее чувствительна к амплитудным флуктуациям сигнала. Ослабление сигнала может варьироваться во времени из-за изменений в транспортной среде, это довольно типично для коммутируемых телефонных сетей. В сетях, использующих выделенные каналы, это также возможно благодаря применению динамических протоколов маршрутизации, когда длина пути может изменяться в пределах одного сеанса связи. В любом случае на передающей стороне необходим модулятор, а на принимающей демодулятор. Так как обмен обычно двунаправлен, эти устройства объединяются в одном приборе, который называется модемом (см. также раздел “4.3.7. Модемы").
В модемах применимы несколько видов модуляции:
| FSK |
(Frequency Shift Keying) - ступенчатое переключение частоты синусоидального сигнала от f1 к f2 при неизменной амплитуде, частоте f1 ставится в соответствие логический нуль, а f2 - логическая единица. |
BPSK |
(Binary Phase-Shift Keying) - скачкообразное переключение фазы синусоидального сигнала на p при неизменной амплитуде, при этом фазе 0 ставится в соответствие логический нуль, а p- логическая единица. |
DPSK |
(Differential Phase Shift Keying) - метод, при котором изменяется фаза несущей частоты при постоянной амплитуде и частоте. Разновидность PSK, при которой кодируется лишь изменение сигнала. |
QAM |
(Quadrature Amplitude Modulation) - комбинация амплитудной и фазовой модуляции, позволяет осуществить кодирование 8 бит на бод. |
QPSK |
(Quadrature Phase-Shift Keying) - квадратурная фазовая модуляция. Использует 4 фиксированных значения фазы 0, p/2, p и 3p/2. Требует в два раза более узкую полосу, чем PSK, и по этой причине весьма популярна. |
|
TCM |
(Trellis Coded Modulation) - метод предполагает использование избыточности, каждый бод несет дополнительный бит, который позволяет более точно восстановить информационную битовую последовательность. При кодировании сигнала используется метод QAM. Метод реализован в современных высокоскоростных модемах и позволяет снизить требования к отношению сигнал/шум на 4-5 дБ. |
Рис. 2.2. QAM-модуляция с 3 битами на бод (слева) и 4 битами на бод (справа)
Причины циклов пакетов и осцилляции маршрутов
5.4 Причины циклов пакетов и осцилляции маршрутов
Семенов Ю.А. (ГНЦ ИТЭФ)
Для рядового пользователя информация данного раздела не может представлять никакого интереса. Некоторые продвинутые пользователи иногда могут обратить внимание на то, что программа traceroute начинает (вместо нормального отображения пути до цели) выдавать попеременно имена двух соседних узлов. Это может позабавить, если конечно не влияет на решение пользователем его текущих задач. Но в любом случае вмешаться и исправить что-либо он не в силах. О причинах такого поведения сети можно прочесть в разделах, посвященных вопросам маршрутизации.
Начнем с локальных сетей. В разделе о мостах 4.1.1.4, там где говорилось об алгоритме “расширяющееся дерево” отмечалась недопустимость того, чтобы две ЭВМ в локальной сети могли соединяться друг с другом различными путями. Здесь подразумевается соединение через систему мостов, повторителей/концентраторов и переключателей. Такого рода соединение через маршрутизаторы допустимо, но и там следует к этому относиться с определенной осторожностью. Рассмотрим фрагмент сети, изображенный на рис. 5.4.1.
Рис. 5.4.1. Пример ошибочной топологии локальной сети
Пакеты от машины 1 через концентратор 1 и 2 попадут в концентратор 2, эти же пакеты попадут туда через мост. В результате возникнет встречное кольцевое движение идентичных пакетов. Кроме того, переключатели и мост попытаются разобраться с этим безобразием и начнут посылать широковешательные пакеты, чтобы выяснить с каким из портов на самом деле связаны эти ЭВМ. Они от рождения убеждены, что одна и та же ЭВМ может быть доступна только через один порт. Таким образом, всплески загрузки сети, особенно широковещательной, должны привлекать внимание администратора. В данном примере, если система переключателей и мостов не поддерживает алгоритма “расширяющееся дерево”, администратор сам должен разорвать эту кольцевую структуру.
Зацикливание пакетов возможно также при использовании внутреннего протокола маршрутизации IGRP, где некорректный выбор параметра вариация приводит к тому, что система при распределении потоков по нескольким направлениям воспринимает путь “назад”, как вполне приемлемый.
Еще один вариант циклов пакетов возникает при использовании маршрутов по умолчанию (более детально это описано в разделе, посвященном маршрутизации 4.4.11). Так при наличии канала между сетями А и Б внешние маршрутизаторы этих сетей сконфигурированы так, что в сети А пакет адресованный не А, направляется в Б, а в сети Б все пакеты с местом назначения не Б, направляются сети А. Такая конфигурация возможна и она будет работать нормально до тех пор, пока в одной из сетей не появится пакет с ошибочным адресом, не соответствующем ни сети А, ни Б. Такой пакет будет двигаться между сетями А и Б до тех пор пока не выработает свой ресурс по TTL.
Похожие проблемы возникают при реализации, например, протокола маршрутизации RIP (см. раздел 4.4.11.1), что сильно замедляет там процедуру установления равновесного маршрута.
Протоколы маршрутизации работают с системами, где имеют место огромные задержки. И как всякая система управления с задержанной обратной связью такие системы склонны к осцилляциям. Допустим некоторый узел, оценив метрику нескольких маршрутов, принял решение перейти на новый маршрут. Если он это сделает, об этом окружающие маршрутизаторы узнают с заметной задержкой и соответствующим образом изменят свои оценки метрик фрагментов пути. Когда (снова с задержкой) исходный маршрутизатор получит информацию об этих оценкам, может случится, что старый маршрут окажется предпочтительнее нового, и все начнется сначала.
Рассмотренные в данном разделе относительно экзотические явления (кроме примера из локальных сетей, здесь имеет место не экзотика, а стихийное бедствие) встречаются не так часто, но администратор сети должен принимать в расчет и такие возможности. Любой из упомянутых эффектов может сильно ухудшить эксплуатационные параметры сети, а то и вовсе вывести ее из строя.
Приложения
10 Приложения
Семенов Ю.А. (ГНЦ ИТЭФ)
Применение го режима сетевого адаптера для целей диагностики
5.3 Применение 6-го режима сетевого адаптера для целей диагностики
Семенов Ю.А. (ГНЦ ИТЭФ)
Использование 6-го режима работы сетевого интерфейса предоставляет необычные возможности администратору и таит в себе немалые угрозы в случае использования его хакером. Как известно практически любая сетевая карта имеет 6 режимов работы. Обычно она работает в 3-ем режиме, воспринимая все пакеты адресованные ей, а также широковещательные и мультикастинг пакеты. В 6-ом же режиме карта пытается принять все пакеты, следующие по сегменту, вне зависимости от адреса места назначения. Если позволяет загрузка и быстродействие сетевого интерфейса, будут восприняты и обработаны все пакеты, следующие по сегменту, к которому подключена ЭВМ, работающая в 6-ом режиме. Именно по этой причине желательно при осуществлении авторизации использовать шифрованный обмен. В противном случае хакер, чья ЭВМ подключена к сетевому сегменту, может получить все пароли, в том числе и привилегированных пользователей. Если шифрование обмена при авторизации недоступно, привилегированные (root) пользователи должны ограничиться работой через консоль. Выполнение привилегированных операций с удаленной ЭВМ не желательно, так как может привести к раскрытию системного пароля.
6-ой режим позволяет проанализировать распределение пакетов по коду протокола, по адресам отправителей или получателей. Определить парциальные значения трафиков отдельного пользователя для различных видов услуг. Некоторые виды из перечисленных данных можно получить из MIB маршрутизатора (например, Accounting database в случае маршрутизаторов CISCO), но 6-й режим предоставляет большую гибкость и возможности.
6-ой режим позволяет проанализировать распределение пакетов по коду протокола, по адресам отправителей или получателей. Определить парциальные значения трафиков отдельного пользователя для различных видов услуг. Некоторые виды из перечисленных данных можно получить из MIB маршрутизатора (например, accounting database в случае маршрутизаторов Cisco), но 6-й режим предоставляет большую гибкость и возможности.
К сожалению, данная методика применима лишь к пакетам, проходящим через сегмент, к которому подключена ЭВМ, работающая в 6-ом режиме (см. рис. 5.3.1).
Рис. 5.3.1.
Выделенная ЭВМ может полностью отслеживать трафик из зоны сети “C” и лишь транзитный поток пакетов для зон “A” “B” и “D” (например, из зоны А в зону D). Пакеты внутреннего трафика для зон А, В и D не доступны.
Принципы формирования кода отклика в системе SMTP
10.14 Принципы формирования кода отклика в системе SMTP
Семенов Ю.А. (ГНЦ ИТЭФ)
1yz
2yz
3yz
4yz
5yz
Вторая цифра кода может иметь следующие значения:
|
x0z |
Синтаксис - эти отклики относятся к синтаксическим ошибкам или к командам синтаксически корректным но примененным неправильно. | |
|
x1z |
Информация - относится к командам, которые запрашивают информацию, например, статусную или справочную. | |
|
x2z |
Соединения - относится к телекоммуникационному каналу. | |
|
x3z |
Пока не определен. | |
|
x4z |
Пока не определен. | |
|
x5z |
Почтовая система - эти отклики индицируют статус получателя или отправителя почты. |
Третья цифра уточняет смысл второй.
