Протокол IGRP

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



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



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

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

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

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

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

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

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

Алгоритм/Имя

"sha1" – указывает, что будет использована аутентификация [SHA1]

(Когда алгоритм является производным от компонента AuthReq)

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

 

"Pay:ppp", где "ppp" может быть установлено равным любому допустимому значению для "iotpbrand" (смотри ниже)

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

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

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

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

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

Следующий список исходных значений BrandId был получен от организаций, которые сипользуют сертификаты протокола SET с 1-го июня 1999:
"Amex" - American Express
"Dankort" – Dankort
"JCB" – JCB
"Maestro" – Maestro
"MasterCard" – MasterCard
"NICOS" – NICOS
"VISA" - Visa
Кроме того определены следующие значения Id видов платежа:
"Mondex"
"GeldKarte"

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




- Начало -  - Назад -  - Вперед -