7.4. Отображение ИРНА
ИРНА-идентификаторы представляют собой дополнение, основанное на национальных алфавитах, к URI-идентификатору. ИРНА-идентификаторы — это последовательности символов Юникода, в то время как URI-идентификаторы — это последовательность символов ASCII-кода. Стандарт RFC-3987 устанавливает правила отображения ИРНА-идентификаторов в URI-идентификаторы. Несмотря на то, что ИРНА-идентификаторы не кодируются непосредственно в полях или расширениях сертификатов, являющиеся их отображением URI-идентификаторы могут включаться в сертификаты и СОС. URI-идентификаторы могут быть включены в субполя «subjectAltName», «issuerAltName», «nameConstraints», «authorityInfoAccess», «subjectInfoAccess» и «cRLDistributionPoints» поля «Расширения» сертификата, последовательности «authorityInformationAccess» и «issuingDistributionPoint» субполя «crlExtensions» («Расширения СОС»). Каждое из этих расширений использует формат обобщённых имён «GeneralName». URI-идентификаторы размещаются в последовательности «uniformResourceIdentifier» в формате «GeneralName», который кодируется как «IA5String».
Для включения ИРНА-идентификаторов в рассматриваемую структуру, прикладные системы и ИТС, придерживающиеся данного стандарта, обязаны преобразовывать ИРНА-идентификаторы в URI-идентификаторы, как это определено в параграфе 3.1 стандарта RFC-3987, с учётом следующих изменений:
На первой итерации, формируем последовательность UCS-символов из оригинального ИРНА-формата в соответствие с NFC-формой, как это определено Вариантом «b» в «Форматах нормирования Юникода».
Выполняем вторую итерацию, использую выходные данные первой итерации.
Прикладные системы и ИТС обязаны не преобразовывать компонент «ireg-name» до выполнения второй итерации.
Прежде чем URI-идентификаторы будут сравниваться, прикладные системы и ИТС, придерживающиеся данного стандарта, обязаны провести комбинацию процедур по их нормированию на основе правил синтаксиса и схемы построения, которые установлены стандартом RFC-3987. А именно, прикладные системы и ИТС, придерживающиеся данного стандарта, обязаны подготовить URI-идентификаторы для их сравнения следующим образом:
Первая итерация. Там, где ИРНА-идентификаторы позволяют использовать ИСНА, следует, в обязательном порядке, преобразовать такие наименования в последовательность ACE-маркеров, как это определено в 7.2.
Вторая итерация. Схема построения и наименование IP-узла нормируются в нижний регистр, как это определено в параграфе 5.3.2.1 стандарта RFC-3987.
Третья итерация. Производим перекодировку октетов в шестнадцатеричный код, как это определено в параграфе 5.3.2.3 стандарта RFC-3987.
Четвёртая итерация. Производим нормирование (удаление) сегмента маршрута, разделённого точками («.» и «..»), как это определено в параграфе 5.3.2.3 стандарта RFC-3987.
Пятая итерация. Если URI-идентификаторы установлены (определены их схемы построения), то прикладной процесс обязан провести их нормирование по правилам схемы построения таких идентификаторов, как это определено в параграфе 5.3.3 стандарта RFC-3987.
Прикладные системы и ИТС, придерживающиеся данного стандарта, обязаны распознавать и нормировать на основе правил построения схемы идентификации следующие схемы: «LDAP», «HTTP», «HTTPS» и «FTP». Если схема не распознана, то пятая итерация исключается.
Если проводится сравнение эквивалентных URI-идентификаторов, то целесообразно, чтобы прикладные системы и ИТС, придерживающиеся данного стандарта, осуществляли сравнение в режиме игнорирования регистра написания символов.
Целесообразно, чтобы прикладные системы и ИТС осуществляли преобразование URI-идентификаторов в Юникод, перед их отображением на дисплее. В частности, целесообразно, чтобы прикладные системы и ИТС, придерживающиеся данного стандарта, осуществляли такое преобразование в соответствие с правилами, представленными в параграфе 3.2 стандарта RFC-3987.