Для того чтобы гарантировать совместимость,

PayReqNetLocn='http://www.example.com/digicash' >

</PayProtocol>

</BrandList>

Соображения IANA

12.1. Коды контролируемые IANA

Для того чтобы гарантировать совместимость, коды, используемые IOTP, нужно поддерживать в контролируемой среде так, что их значения и использование были строго определены, а дублирование кодов должно быть исключено. IANA представляет механизм решения этой проблемы, как это описано в RFC 2434.

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

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

торговый подписной лист IETF имеет адрес

"Специальные эксперты (Designated Experts)" (смотри [IANA]) назначаются IESG.

Тип элемента/Имя атрибута	Значения атрибутов
Алгоритм/Имя	"sha1" - указывает, что будет использована аутентификация [SHA1]
(Когда алгоритм является производным от компонента AuthReq)	"Подпись" - указывает, что аутентификация включает в себя генерацию цифровой подписи.
	"Pay:ppp", где "ppp" может быть установлено равным любому допустимому значению для "iotpbrand" (смотри ниже)

За исключением алгоритмов, которые начинаются с "pay:", новые значения выделяются после просмотра торгового почтового списка IETF и с привлечением “специального эксперта”.

Элемент Algorithm обычно определяется в пределах пространства имен [DSIG]. Со временем эта процедура может измениться.

Тип элемента/Имя атрибута

Значения атрибутов

Вид платежа/BrandId

Следующий список исходных значений BrandId был получен от организаций, которые сипользуют сертификаты протокола SET с 1-го июня 1999:

"Amex" - American Express

"Dankort" - Dankort

"JCB" - JCB

"Maestro" - Maestro

"MasterCard" - MasterCard

"NICOS" - NICOS

"VISA" - Visa

Кроме того определены следующие значения Id видов платежа:

"Mondex"

"GeldKarte"

<

Содержание Назад Вперед