Network Working Group Request for Comments: 4518 Категория: Standards Track K. Zeilenga, OpenLDAP Foundation Июнь 2006 года
Этот документ определяет проект стандарта протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) Internet Society (2006).
В предыдущей технической спецификации протокола Lightweight Directory Access Protocol (LDAP) не давалось точного определения тому, как должно выполняться сравнение символьных строк. Это привело к ряду проблем в областях удобства и простоты использования, а также совместимости. В этом документе определяются алгоритмы подготовки строк для определённых к использованию в LDAP правил соответствия, оперирующих с символьными строками.
Правило соответствия [RFC4517] протокола LDAP [RFC4510] задаёт алгоритм для определения того, соответствует ли представленное значение значению атрибута согласно критериям, определённым для данного правила. Утверждение может быть оценено как True, False или Undefined.
True — в атрибуте содержится соответствующее значение,
False — в атрибуте не содержится соответствующее значение,
Undefined — невозможно определить, содержится ли в атрибуте соответствующее значение.
Например, правило соответствия caseIgnoreMatch может быть использовано для определения того, содержит ли атрибут commonName конкретное значение, без учёта регистра символов и незначимых пробелов.
Стандарт X.520 "The Directory: Selected attribute types" [X.520] определяет (помимо прочего) синтаксисы значений и правила соответствия для сравнения обычно используемых в каталоге X.500 значений. Эти спецификации не подходят для строк, состоящих из символов Unicode [Unicode].
К примеру, правило соответствия caseIgnoreMatch в X.520 определяется просто как сравнение без учёта регистра символов с игнорированием незначимых пробелов. Для значений printableString, где только один пробельный символ и отображение регистра символов является биективным, такого определения достаточно. Однако, для Unicode-строковых типов, таких как universalString, оно недостаточно. Например, реализации сравнения без учёта регистра символов, преобразующие символы в нижнем регистре в верхний, будут выдавать результаты, отличающиеся от результатов реализаций сравнения, преобразующих верхний регистр символов в нижний. Или же, в одной реализации пробелы могут рассматриваться как только символ SPACE (U+0020), во второй — как любой символ со свойством space separator (Zs), а в третьей — как любой символ с категорией whitespace (WS).
Отсутствие точной спецификации соответствия символьных строк привело к значительным проблемам с совместимостью. Если такие сравнения выполняются при проверке цепочки сертификатов, это может привести к уязвимости в системе безопасности. Для решения этих проблем в данном документе определяются точные алгоритмы подготовки символьных строк для сравнения.
Описанные в этом документе алгоритмы подготовки символьных строк основаны на подходе "stringprep" [RFC3454]. В "stringprep" предоставляемые и хранимые значения сначала подготавливаются для сравнения, поэтому посимвольное сравнение даёт "правильный" результат.
Описанный в данном документе подход является усовершенствованием подхода "stringprep" [RFC3454]. Каждый алгоритм включает в себя два дополнительных шага подготовки:
Таким образом, подготовка строки для сравнения [X.501] в X.500 включает в себя следующие шаги:
Данные шаги описаны в разделе 2.
Обратите внимание, что, несмотря на то, что различные таблицы символов Unicode, которые включены в данную спецификацию, или на которые она ссылается, получены из данных Unicode [Unicode], эти таблицы должны считаться окончательными при реализации данной спецификации.
Данный документ является неотъемлемой частью технической спецификации LDAP [RFC4510], полностью отменяющей ранее определённую техническую спецификацию LDAP [RFC3377].
В данном документе определяются новые алгоритмы подготовки интернационализированных символьных строк LDAP, используемые в [RFC4517] и, возможно, в других технических спецификациях, определяющих синтаксисы и/или правила соответствия LDAP.
LDAP [RFC4510] определён в терминах X.500 как механизм доступа к каталогам X.500. Поэтому, крайне желательно соблюдать принцип взаимности преобразований между синтаксисами и семантиками LDAP и X.500. Описанные в этом документе алгоритмы подготовки символьных строк основанны на правилах "Internationalized String Matching Rules for X.500" [XMATCH], предложенных ITU/ISO Joint Study Group 2.
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в BCP 14 [RFC2119].
Для именования символов в этом документе используются обозначения кодов и имён из стандарта Unicode [Unicode]. Например, буква "a" может быть представлена как <U+0061>, либо как <LATIN SMALL LETTER A>. В списках отображений и запрещённых символов для упрощения чтения начальное "U+" опускается. Комментарии по поводу диапазонов символов показаны в квадратных скобках (например, "[CONTROL CHARACTERS]"), они не являются частью стандарта Unicode.
Примечание: глоссарий используемых в Unicode терминов можно найти в источнике [Glossary]. Информацию о модели кодирования символов Unicode можно найти в источнике [CharModel].
Используемый в этой спецификации термин "метки комбинирования", указывает на любой код Unicode [Unicode], у которого имеется свойство метки (Mn, Mc, Me). В приложении A приведён исчерпывающий список меток комбинирования.
Для подготовки к сравнению с использованием правила соответствия, применяемого к символьным строкам, к каждому предоставляемому значению и значению атрибута нужно (SHALL) применить следующий процесс, состоящий из шести шагов:
Неудачное завершение любого из этих шагов приводит к тому, что предоставленное утверждение оценивается как Undefined.
Множество символов, с которыми работает этот процесс: Unicode 3.2 [Unicode].
Имейте ввиду, что спецификация данного процесса из шести шагов предназначается для описания ожидаемого поведения при выполнении сравнения. Разработчики вольны использовать альтернативные процессы, если их поведение при выполнении оценки по правилу соответствия согласуется с поведением, описанным в данной спецификации.
Каждое строковое значение в отличном от Unicode формате транскодируется в Unicode.
Значения PrintableString [X.680] транскодируются непосредственно в Unicode.
Значения UniversalString, UTF8String и bmpString [X.680] транскодировать не требуется, поскольку они представляют собой основанные на Unicode строки (в случае bmpString — основанные на подмножестве Unicode).
Значения TeletexString [X.680] транскодируются в Unicode. Поскольку стандарта для отображения значений TeletexString в Unicode нет, порядок такого отображения оставляется на усмотрение разработчиков.
По этой и другим причинам использовать TeletexString не рекомендуется (NOT RECOMMENDED).
На выходе этого шага получается транскодированная строка.
Коды SOFT HYPHEN (U+00AD) и MONGOLIAN TODO SOFT HYPHEN (U+1806) отображаются в ничто. Коды COMBINING GRAPHEME JOINER (U+034F) и VARIATION SELECTORs (U+180B-180D, FE00-FE0F) также отображаются в ничто. OBJECT REPLACEMENT CHARACTER (U+FFFC) отображается в ничто.
Коды CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR) (U+000D) и NEXT LINE (NEL) (U+0085) отображаются в SPACE (U+0020).
Все остальные контрольные коды (например, Cc) или коды с контрольной функцией (например, Cf) отображаются в ничто. Полный список таких кодов: U+0000-0008, 000E-001F, 007F-0084, 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063, 206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F.
ZERO WIDTH SPACE (U+200B) отображается в ничто. Все остальные коды со свойством разделителя (пробела, строки или параграфа) (например, Zs, Zl или Zp) отображаются в SPACE (U+0020). Полный список таких кодов: U+0020, 00A0, 1680, 2000-200A, 2028-2029, 202F, 205F, 3000.
Для правил соответствия с игнорированием регистра символов, правил соответствия для числовых строк и строк с сохранённым префиксом, унификация регистра символов выполняется согласно пункту B.2 RFC3454.
На выходе этого шага получается отображённая строка.
Входная строка должна быть нормализована в Unicode Form KC (форма, подготовленная с учётом совместимости), как описано в [UAX15]. На выходе этого шага получается нормализованная строка.
Все неназначенные коды запрещены. Неназначенные коды перечислены в таблице A.1 RFC3454.
Символы, которые (согласно разделу 5.8 RFC3454) изменяют параметры экрана, либо являются устаревшими, запрещены. Такие символы перечислены в таблице C.8 RFC3454.
Коды, выделенные для частного использования, запрещены. Такие символы перечислены в таблице C.3 RFC3454.
Все несимвольные коды запрещены. Такие коды перечислены в таблице C.4 RFC3454.
Суррогатные коды запрещены. Такие символы перечислены в таблице C.5 RFC3454.
Код REPLACEMENT CHARACTER (U+FFFD) запрещён.
Данный шаг завершается неудачей, если во входной строке содержится запрещённый код. В противном случае, на выход этого шага передаётся входная строка.
Двунаправленные символы игнорируются.
На этом шаге строка модифицируется так, чтобы обеспечить надлежащую обработку символов, незначительных для конкретного правила соответствия. Такая модификация отличается для разных правил соответствия.
К правилам соответствия с учётом и без учёта регистра символов применяется модификация, описанная в разделе 2.6.1.
К правилам соответствия, оперирующим со строками numericString, применяется модификация, описанная в разделе 2.6.2.
К правилам соответствия, оперирующим со строками telephoneNumber, применяется модификация, описанная в разделе 2.6.3.
В этом разделе пробел определяется как код SPACE (U+0020), за которым не следуют никакие метки комбинирования.
ПРИМЕЧАНИЕ: Выполнение предыдущих шагов даёт гарантию того, что входная строка не может содержать никаких кодов из класса разделителей, кроме SPACE (U+0020).
Для входных строк, представляющих собой значение атрибута или значение утверждения, не являющееся подстрокой: если во входной строке не содержится непробельных символов, то выходная строка будет представлять собой ровно два символа SPACE. В противном случае (во входной строке присутствует хотя бы один непробельный символ), эта строка модифицируется таким образом, что она будет начинаться ровно с одного символа SPACE, заканчиваться ровно одним символом SPACE, и любые внутренние (не пустые) последовательности пробельных символов будут заменены на ровно два символа SPACE. Например, входная строка
"foo<SPACE>bar<SPACE><SPACE>"
в результате преобразования даст на выходе
"<SPACE>foo<SPACE><SPACE>bar<SPACE>"
Для входных строк, представляющих собой значение утверждения, являющееся подстрокой: если в подготавливаемой строке не содержится непробельных символов, то выходная строка будет представлять собой ровно один символ SPACE. В противном случае выполняются следующие шаги:
Например, для входной строки
"foo<SPACE>bar<SPACE><SPACE>"
если она представляет собой initial-подстроку, выходная строка будет:
"<SPACE>foo<SPACE><SPACE>bar<SPACE>"
Если же она представляет собой any-подстроку или final-подстроку, та же входная строка даст на выходе:
"foo<SPACE><SPACE>bar<SPACE>"
Обоснование такого поведения обсуждается в приложении B.
В этом разделе пробел определяется как код SPACE (U+0020), за которым не следуют никакие метки комбинирования.
Все пробелы рассматриваются как незначительные и должны быть удалены.
Например, при удалении пробелов из такой Form KC-строки:
"<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
получится выходная строка:
"123456"
А при удалении пробелов из такой Form KC-строки:
"<SPACE><SPACE><SPACE>"
получится выходная строка:
""
(то есть, пустая строка).
В этом разделе дефис определяется как символ с кодом HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010), NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS (U+FE63) или FULLWIDTH HYPHEN-MINUS (U+FF0D), за которым не следуют никакие метки комбинирования, пробел определяется как код SPACE (U+0020), за которым не следуют никакие метки комбинирования.
Все дефисы и пробелы рассматриваются как незначительные и должны быть удалены.
Например, при удалении дефисов и пробелов из такой Form KC-строки::
"<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
получится выходная строка:
"123456"
А при удалении дефисов и пробелов из такой Form KC-строки:
"<HYPHEN><HYPHEN><HYPHEN>"
получится выходная строка (пустая):
""
Соображения безопасности, приведённые в "Preparation of Internationalized Strings ("stringprep")" [RFC3454], в целом относятся и к описанным здесь алгоритмам.
Используемый в данном документе подход основан на принципах построения и алгоритмах, описанных в "Preparation of Internationalized Strings ("stringprep")" [RFC3454], авторы Paul Hoffman и Marc Blanchet. Некоторые дополнительные указания были взяты из технических стандартов, технических отчётов и замечаний по Unicode.
Данный документ — продукт рабочей группы IETF LDAP Revision (LDAPBIS).
[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[RFC3454] Hoffman, P. и M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, декабрь 2002 г.
[RFC4510] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC4510, июнь 2006 г.
[RFC4517] Под редакцией Legg, S., "Lightweight Directory Access Protocol (LDAP): Синтаксисы и правила соответствия", RFC 4517, июнь 2006 г.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" определён в "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), с изменениями, внесенными "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) и "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[UAX15] Davis, M. и M. Duerst, "Unicode Standard Annex #15: Unicode Normalization Forms, Version 3.2.0". <http://www.unicode.org/unicode/reports/tr15/tr15-22.html>, март 2002 г.
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
[X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994).
[X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[X.520] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Selected Attribute Types", X.520(1993) (also ISO/IEC 9594-6:1994).
[Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report #17, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr17/>, август 2000 г.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, сентябрь 2002 г.
[RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, июнь 2006 г.
[XMATCH] Zeilenga, K., "Internationalized String Matching Rules for X.500", в разработке.
Это приложение является нормативным.
Следующая таблица была получена из файлов данных Unicode [Unicode]; в ней перечислены все коды со свойствами Mn, Mc или Me. При реализации данной спецификации эта таблица должна рассматриваться как исчерпывающая.
0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1
05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670
06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A
07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963
0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7
09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D
0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD
0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57
0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03
0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83
0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03
0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA
0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A
0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19
0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97
0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714
1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9
20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23
1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B
1D1AA-1D1AD
Это приложение не является нормативным.
При отсутствии необходимости определения соответствия подстрок, обработка малозначительных пробельных символов для выполнения сравнения с учётом и без учёта регистра символов может быть упрощена. В частности, такая обработка может заключаться в выдвижении требования, чтобы все последовательности из одного или более пробельных символов были заменены одним пробелом и, если строка содержит непробельные символы, чтобы все начальные и конечные пробелы были удалены.
Если необходимость определения соответствия подстрок есть, то такая упрощённая обработка пробельных символов приведет к непредсказуемому и нежелательному поведению при выполнении сравнения. Например:
Примечание для читателей, не знакомых с порядком определения соответствия с подстроками в LDAP: утверждение в LDAP-фильтре [RFC4515] (CN=A*B*C) говорит: "найти совпадение с любым значением (атрибута CN), которое начинается на A, содержит B после A, и заканчивается на C, где C также должно быть после B."
Первый пример показывает, что такая упрощенная обработка пробелов приведёт к тому, что начальные и конечные пробелы в подстроках строки значения утверждения будут рассматриваться как незначительные. Однако незначительными являются только начальные и конечные пробелы (а также несколько пробелов, следующих друг за другом) строки в целом.
Второй пример показывает, что такая упрощенная обработка пробелов приведёт к сбоям при разбиении на подстроки. То есть, если подготовленная any-подстрока соответствует части значения атрибута, то утверждение, построенное путём разделения этой подстроки на несколько подстрок, также должно соответствовать части значения атрибута.
При разработке приемлемого подхода обработки малозначительных пробельных символов для определения соответствия подстрок, необходимо изучить ключевые аспекты поиска соответствия с учётом и без учёта регистра символов в X.500. В стандарте X.520 сказано:
Правило типа [substrings] возвращает TRUE, если имеет место разбиение значения атрибута (на части) таким образом, что:
- заданные подстроки (initial, any, final) соответствуют разным частям этого значения в порядке последовательности указания этих подстрок;
- подстрока initial, если таковая присутствует, соответствует первой части этого значения;
- подстрока final, если таковая присутствует, соответствует последней части этого значения;
- подстрока any, если таковая присутствует, соответствует некоторой произвольной части этого значения.
То есть, утверждение с подстроками
(CN=foo\20*\20bar)
соответствует значению атрибута
"foo<SPACE><SPACE>bar"
, поскольку данное значение может быть разбито на части
"foo<SPACE>"
и
"<SPACE>bar"
, отвечающие вышеуказанным требованиям.
Также в стандарте X.520 сказано:
В качестве незначительных рассматриваются следующие пробельные символы:
- начальные пробелы (то есть те, которые предшествуют первому символу, не являющемуся пробелом);
- конечные пробелы (то есть те, которые следуют за последним символом, не являющимся пробелом);
- несколько пробелов, следующих друг за другом (они рассматриваются как эквивалент одного символа пробела).
Это правило применяется к значениям утверждения и значениям атрибута как к целым строкам, и не применяется к отдельным подстрокам в значении утверждения. В частности, данное правило следует понимать в том смысле, что если значение утверждения и значение атрибута соответствуют друг другу без какой-либо обработки малозначительных символов, то это значение утверждения должно также соответствовать любому значению атрибута, отличающемуся от первоначального только тем, что в него были включены или из него были удалены малозначительные символы.
Поэтому утверждение
(CN=foo\20*\20bar)
соответствует строкам
"foo<SPACE><SPACE><SPACE>bar"
и
"foo<SPACE>bar"
, поскольку они отличаются от
"foo<SPACE><SPACE>bar"
лишь включением или удалением незначительных пробелов.
Внимательные читатели этого текста также обратят внимание на то, что существуют специальные случаи, когда указанная обработка пробельных символов не игнорирует те из них, которые могли бы рассматриваться как незначительные. Например, утверждение
(CN=\20*\20*\20)
не соответствует строке
"<SPACE><SPACE><SPACE>"
(в значении есть незначительные пробелы) или строке
" "
(в значении нет незначительных пробелов). Однако, поскольку эти случаи не имеют никакого практического применения и могут быть заменены простыми утверждениями, например,
(cn=\20)
а также потому, что такая незначительная аномалия может быть полностью разрешена только путём использования алгоритма подготовки в сочетании с посимвольным разбиением и согласованием, данная аномалия считается приемлемой.
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Copyright (C) Internet Society (2006).
На этот документ распространяются права, лицензии и ограничения, содержащиеся в BCP 78, и, за исключением случаев, изложенных в нем, авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и АВТОР ДОКУМЕНТА, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ, ИЛИ КОТОРОЙ ОН/ОНА СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВЫЕ ИМЕЮТСЯ), INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
IETF не занимает никакой позиции относительно действительности или области действия каких-либо прав на интеллектуальную собственность, или других прав, которые могут заявляться как относящиеся к реализации или использованию технологий, описанных в данном документе, либо в подтверждении которых могут или не могут быть доступны какие-либо лицензии; кроме того, IETF не заявляет о том, что она будет предпринимать какие-либо независимые усилия по выявлению подобных прав. Информацию по процедурам в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.
Копии поданных в секретариат IETF заявлений о правах на интеллектуальную собственность (Intellectual Property Rights, IPR), а также какие-либо документы, подтверждающие лицензию и предназначенные для предоставления доступа к ним, либо результаты попыток получения генеральных лицензий или разрешений на пользование подобными правами собственности могут быть получены теми, кто занимается реализацией, или пользователями данной спецификации из он-лайн репозитория IPR IETF по адресу http://www.ietf.org/ipr.
IETF просит всех заинтересованных лиц довести до её сведения любые авторские права, патенты или патентные заявки, либо другие права собственности, которые могут касаться технологий данного стандарта и могут потребоваться для его реализации. Пожалуйста, направляйте информацию в IETF по адресу ietf-ipr@ietf.org.
Финансирование функций RFC Editor обеспечивается IETF Administrative Support Activity (IASA).