Коды контролируемые 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: |
Новые значения BrandId должны быть опубликованы через торговый подписной лист IETF и, если в течение трех недель не поступает возражений, они присваиваются в порядке поступления.
Валютная сумма/CurrCode | Коды валюты зависят от CurrCodeType (смотри ниже). |
Если CurrCodeType = "ISO4217-A", тогда код валюты является буквенным, определенным в [ISO4217].
Если 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" |
RelatedTo/RelationshipType | "IotpTransaction" "Reference" |
Тип элемента/Имя атрибута | Значения атрибута |
Значения Status/StatusType | Значения Предложение Платеж Доставка Аутентификация Не идентифицировано Новые значения атрибута Status Type выделяются после:oпубликации в Торговой Рабочей Группе IETF, документа RFC, описывающего торговый обмен, торговые роли и соответствующие компоненты, которые относятся к Status и oрассмотрения документа в торговом почтовом листе IETF и экспертами. |
TradingRole/TradingRole | "Consumer" "Merchant" "PaymentHandler" "DeliveryHandler" "DelivTo" oпубликации в Торговой Рабочей Группе IETF, документа RFC, описывающего торговый обмен, торговые роли и соответствующие компоненты, которые относятся к Trading Role и oрассмотрения документа в торговом почтовом листе IETF и экспертами. |
Документ, описывающий новые значения атрибута Trading Role может быть объединен с документами, описывающими новые значения Status Types (смотри выше) и типы подписей (смотри ниже).
Тип элемента/Имя атрибута | Значения атрибута |
TransId/IotpTransType | "BaselineAuthentication" "BaselineDeposit" "BaselineRefund" "BaselineWithdrawal" "BaselineValueExchange" "BaselineInquiry" "BaselinePing" Новые значения атрибута IotpTransType выделяются после: oпубликации через почтовый список IETF, в виде документа RFC, описывающего новую транзакцию IOTP и oрассмотрения документа в почтовом списке торговой рабочей группы IETF и экспертами. |
Attribute/Content (смотри компонент Signature) | "OfferResponse" "PaymentResponse" "DeliveryResponse" "AuthenticationRequest" "AuthenticationResponse" "PingRequest" "PingResponse" Новые значения кода, которые описывают тип подписи выделяются после: oпубликации в Торговой Рабочей Группе IETF документа RFC, описывающего торговый обмен, где используются подписи и oрассмотрения документа в торговом почтовом листе IETF и экспертами. |