Соображения IANA
12. Соображения IANA
12.1. Коды контролируемые IANA
Для того чтобы гарантировать совместимость, коды, используемые IOTP, нужно поддерживать в контролируемой среде так, что их значения и использование были строго определены, а дублирование кодов должно быть исключено. IANA представляет механизм решения этой проблемы, как это описано в RFC 2434.
Типы элементов и имена атрибутов, к которым эта процедура применяется, приведены ниже в таблице вместе с исходными величинами, разрешенными для этих атрибутов.
Заметим, что:
- торговый подписной лист IETF имеет адрес
- "Специальные эксперты (Designated Experts)" (смотри [IANA]) назначаются IESG.
| Тип элемента/Имя атрибута | Значения атрибутов |
| Алгоритм/Имя | "sha1" – указывает, что будет использована аутентификация [SHA1] |
| (Когда алгоритм является производным от компонента AuthReq) | "Подпись" – указывает, что аутентификация включает в себя генерацию цифровой подписи. |
| "Pay:ppp", где "ppp" может быть установлено равным любому допустимому значению для "iotpbrand" (смотри ниже) |
За исключением алгоритмов, которые начинаются с "pay:", новые значения выделяются после просмотра торгового почтового списка IETF и с привлечением “специального эксперта”.
Элемент Algorithm обычно определяется в пределах пространства имен [DSIG]. Со временем эта процедура может измениться.
Тип элемента/Имя атрибута |
Значения атрибутов |
| Вид платежа/BrandId | Следующий список исходных значений BrandId был получен от организаций, которые сипользуют сертификаты протокола SET с 1-го июня 1999: "Amex" - American Express "Dankort" – Dankort "JCB" – JCB "Maestro" – Maestro "MasterCard" – MasterCard "NICOS" – NICOS "VISA" - Visa Кроме того определены следующие значения Id видов платежа: "Mondex" "GeldKarte" |
Новые значения BrandId должны быть опубликованы через торговый подписной лист IETF и, если в течение трех недель не поступает возражений, они присваиваются в порядке поступления.
| Валютная сумма/CurrCode | Коды валюты зависят от CurrCodeType (смотри ниже). |
Если CurrCodeType = "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" |
Это может потребовать публикации дополнительной документации, описывающей как осуществляется метод доставки.
| Тип элемента/Имя атрибута | Значения атрибута |
| 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 и экспертами. |
Документ, описывающий новые значения типа подписи, может быть объединен с документами, описывающими новые типы Status и торговые роли (смотри выше).
12.2. Коды, неконтролируемые IANA
Помимо формального выбора и регистрации кодов, как это описано выше, для разработчиков существует необходимость экспериментировать с новыми кодами IOTP. По этой причине могут использоваться "коды определенные пользователем", что не требует регистрациив IANA. Определение кода, задаваемого пользователем, выглядит следующим образом:
user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*
| NameChar | NameChar имеет то же определение, что и [XML] определение NameChar. |
