Перевод выполнен участниками проекта. Предложения по улучшению перевода и сообщения об ошибках принимаются на форуме проекта.
Статус документа
В этом документе определяется предложенный стандарт протокола Internet для сообщества Internet, а также принимаются обсуждения и предложения по его улучшению. Пожалуйста, отслеживайте текущую редакцию "Internet Official Protocol Standards" (STD 1) на предмет состояния стандартизации и статуса данного протокола. Ограничений на распространение этого документа не накладывается.
Уведомление об авторских правах
Copyright (C) Internet Society (2000). Все права защищены.
Тезисы
В этом документе описывается формат представления данных, предназначенный для описания информации, содержащейся в каталоге, либо описания модификаций, производимых над содержащейся в каталоге информацией. Данный формат, известный как LDIF, аббревиатура от LDAP Data Interchange Format, обычно используется для импорта и экспорта содержащейся в каталоге информации между серверами каталогов, основанными на LDAP, либо для описания набора изменений, которые требуется применить к каталогу.
Предпосылки и предназначение
Существует ряд ситуаций, для которых желателен общий формат обмена данными. Например, кто-то может захотеть экспортировать копию содержимого сервера каталогов в файл, переместить файл на другую машину и импортировать содержимое во второй сервер каталогов.
Кроме того, использование чётко определённого формата обмена облегчает разработку инструментов импорта данных из систем, данные которых требуется унаследовать. Например, с помощью довольно простого набора инструментов, написанного на awk или perl, можно переконвертировать базу данных персональной информации в LDIF-файл. Затем этот файл можно импортировать в сервер каталогов, независимо от того, какое внутреннее представление базы данных использует целевой сервер каталогов.
Формат LDIF изначально был разработан и использовался в реализации LDAP Мичиганского Университета. Сначала LDIF использовался для описания записей каталога. Позднее формат был расширен, чтобы можно было представлять изменения записей каталога.
Взаимоотношения с типом содержимого MIME application/directory:
Тип содержимого MIME application/directory [1] представляет собой общую структуру и формат для передачи информации каталога, независящие от какого-либо конкретного сервиса каталога. Формат LDIF — более простой формат, с которым проще работать и, как уже было сказано, с его помощью можно описывать набор изменений, применяемых к каталогу.
Используемые в этом документе ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "MAY" (возможно), "SHOULD" (следует) и "SHOULD NOT" (не следует) должны интерпретироваться как описано в [7].
Определение LDAP Data Interchange Format
Формат LDIF используется для выражения информации каталога или описания набора изменений, производимых над записями каталога. Файл LDIF состоит из серий записей, отделённых друг от друга строками-разделителями. Запись файла состоит из последовательности строк, описывающих запись каталога, или последовательности строк, описывающих набор изменений записи каталога. Файл LDIF определяет набор записей каталога или набор изменений, применяемых к записям каталога, но не то и другое сразу.
Существует однозначное соответствие между операциями LDAP модификации каталога (add, delete, modify и modrdn) и типами описанных ниже записей изменений changerecord ("add", "delete", "modify" и "modrdn" (или "moddn")). Это соответствие является преднамеренным и позволяет вызывать операции протокола простой трансляцией записей changerecord файла LDIF.
Формальный синтаксис определения LDIF
Приведённое ниже определение использует расширенную форму Бэкуса-Наура, определённую в RFC 2234 [2].
ldif-file = ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-changes = version-spec 1*(1*SEP ldif-change-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
ldif-change-record = dn-spec SEP *control changerecord
version-spec = "version:" FILL version-number
version-number = 1*DIGIT
; version-number должен (MUST) быть "1" для
; формата LDIF, описанного в этом документе.
dn-spec = "dn:" (FILL distinguishedName /
":" FILL base64-distinguishedName)
distinguishedName = SAFE-STRING
; отличительное имя, как определено в [3]
base64-distinguishedName = BASE64-UTF8-STRING
; distinguishedName, закодированное base64
; (смотрите примечание 10 ниже)
rdn = SAFE-STRING
; относительное отличительное имя, определённое как
; <name-component> в [3]
base64-rdn = BASE64-UTF8-STRING
; rdn, закодированное base64
; (смотрите примечание 10 ниже)
control = "control:" FILL ldap-oid ; controlType
0*1(1*SPACE ("true" / "false")) ; criticality
0*1(value-spec) ; controlValue
SEP
; (смотрите примечание 9 ниже)
ldap-oid = 1*DIGIT 0*1("." 1*DIGIT)
; LDAPOID, как определено в [4]
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" ( FILL 0*1(SAFE-STRING) /
":" FILL (BASE64-STRING) /
"<" FILL url)
; Смотрите примечания 7 и 8 ниже
url = <a Uniform Resource Locator,
как определено в [6]>
; (смотрите примечание 6 ниже)
AttributeDescription = AttributeType [";" options]
; Определение взято из [4]
AttributeType = ldap-oid / (ALPHA *(attr-type-chars))
options = option / (option ";" options)
option = 1*opt-char
attr-type-chars = ALPHA / DIGIT / "-"
opt-char = attr-type-chars
changerecord = "changetype:" FILL
(change-add / change-delete /
change-modify / change-moddn)
change-add = "add" SEP 1*attrval-spec
change-delete = "delete" SEP
change-moddn = ("modrdn" / "moddn") SEP
"newrdn:" ( FILL rdn /
":" FILL base64-rdn) SEP
"deleteoldrdn:" FILL ("0" / "1") SEP
0*1("newsuperior:"
( FILL distinguishedName /
":" FILL base64-distinguishedName) SEP)
change-modify = "modify" SEP *mod-spec
mod-spec = ("add:" / "delete:" / "replace:")
FILL AttributeDescription SEP
*attrval-spec
"-" SEP
SPACE = %x20
; ASCII SP, space
FILL = *SPACE
SEP = (CR LF / LF)
CR = %x0D
; ASCII CR, carriage return
LF = %x0A
; ASCII LF, line feed
ALPHA = %x41-5A / %x61-7A
; A-Z / a-z
DIGIT = %x30-39
; 0-9
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1
UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F
; любое значение <= 127 (десятичное), за исключением
; NUL, LF и CR
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
%x21-39 / %x3B / %x3D-7F
; любое значение <= 127, за исключением NUL, LF, CR,
; SPACE, двоеточие (":", ASCII 58 десятичное)
; и знак меньше ("<", ASCII 60 десятичное)
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 /
UTF8-4 / UTF8-5 / UTF8-6
UTF8-STRING = *UTF8-CHAR
BASE64-UTF8-STRING = BASE64-STRING
; должна (MUST) быть UTF8-STRING,
; закодированная base64
BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
%x61-7A
; +, /, 0-9, =, A-Z, and a-z
; как определно в [5]
BASE64-STRING = [*(BASE64-CHAR)]
Примечания по синтаксису LDIF
Для описанного в этом документе формата LDIF номер версии должен (MUST) быть "1". При отсутствии номера версии те, кто занимается реализацией, могут (MAY) интерпретировать содержимое либо как формат, описанный в этом документе, либо как старый формат файлов LDIF, поддерживаемый реализацией ldap-3.3 Мичиганского Университета [8].
Любая непустая строка в файле LDIF, включая строки комментариев, может (MAY) быть разбита на несколько строк путём вставки разделителя строк (SEP) и пробела SPACE. Недопустимо (MUST NOT) разбиение строки перед первым символом в этой строке. Другими словами, разбиение строки на две строки, первая из которых пуста, не разрешается. Любая строка, начинающаяся с единичного пробела, должна (MUST) рассматриваться как продолжение предыдущей (непустой) строки. При объединении разделённых строк должен быть отброшен ровно один символ пробела из каждой строки-продолжения. Тем, кто занимается реализацией, не следует (SHOULD NOT) разбивать строки так, чтобы при этом разбивались мультибайтовые символы UTF-8.
Любая строка, начинающаяся с символа решётки ("#", ASCII 35), является строкой комментария и при разборе LDIF-файла должна (MUST) быть проигнорирована.
Любое dn или rdn, содержащее символы, отличные от тех, которые определены как "SAFE-UTF8-CHAR", или начинающееся с символов, отличных от тех, которые определены как "SAFE-INIT-UTF8-CHAR" выше, должно (MUST) быть закодировано base-64. Другие значения могут (MAY) быть закодированы base-64. Любые значения, содержащие символы, отличные от тех, которые определены как "SAFE-CHAR", или начинающиеся с символов, отличных от тех, которые определены как "SAFE-INIT-CHAR" выше, должны (MUST) быть закодированы base-64. Другие значения могут (MAY) быть закодированы base-64.
Если непосредственно в LDIF-файл требуется включить значение атрибута нулевой длины, оно должно (MUST) быть представлено как AttributeDescription ":" FILL SEP. Например, "seeAlso:", за которым следует переход на новую строку, представляет собой значение нулевой длины атрибута "seeAlso". Также допустимо, чтобы значение, на которое ссылается URL, было нулевой длины.
Если в attrval-spec указывается URL, применяются следующие соглашения:
Реализациям следует (SHOULD) поддерживать формат URL file://. Содержимое файла, на который ссылается URL, должно быть дословно включено в интерпретируемый вывод данного LDIF-файла.
Реализации могут (MAY) поддерживать другие форматы URL. Семантики, ассоциируемые с каждым поддерживаемым форматом URL, должны быть задокументированы в прилагаемых к реализации заявлениях о соответствии (Applicability Statement).
Отличительные имена, относительные отличительные имена и значения атрибутов с синтаксисом DirectoryString должны (MUST) быть корректными строками UTF-8. Реализации, читающие LDIF, могут (MAY) интерпретировать файлы, в которых эти объекты хранятся в какой-либо иной кодировке символов, но реализации не должны (MUST NOT) генерировать LDIF, не содержащий корректных UTF-8 данных.
Значения отличительных имён, оканчивающиеся на символ пробела SPACE, должны (SHOULD) быть закодированы base-64.
При включении элементов управления (control) в LDIF-файл реализации могут (MAY) избрать игнорирование некоторых из них или даже всех. Это может быть необходимо, если описываемые в этом LDIF-файле изменения передаются подключению по протоколу LDAPv2 (который не поддерживает элементов управления), или какой-то конкретный элемент управления не поддерживается удалённым сервером. Если поле criticality элемента управления установлено в "true", то реализации либо должны (MUST) включать этот элемент управления, либо не должны (MUST NOT) отправлять данную операцию на удалённый сервер.
Если attrval-spec, distinguishedName или rdn закодированы base-64, применяются определённые в [5] правила кодирования со следующими исключениями:
Требование, что поток вывода base-64 должен быть представлен в виде строк размером не более 76 символов, не применяется. Строки в файлах LDIF могут разбиваться только согласно правилам разбиения, описанным выше в примечании 2.
В [5] указывается, что строки, закодированные base-64, могут содержать символы, отличные от набора, определённого как BASE64-CHAR, и такие символы игнорируются. LDIF не разрешает использование каких-либо посторонних символов, кроме тех, которые используются для разбиения строк.
Примеры LDAP Data Interchange Format
Пример 1: Простой LDAP-файл с двумя записями
version: 1 dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com objectclass: top objectclass: person objectclass: organizationalPerson cn: Barbara Jensen cn: Barbara J Jensen cn: Babs Jensen sn: Jensen uid: bjensen telephonenumber: +1 408 555 1212 description: A big sailing fan. dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com objectclass: top objectclass: person objectclass: organizationalPerson cn: Bjorn Jensen sn: Jensen telephonenumber: +1 408 555 1212
Пример 2: Файл, содержащий запись с разбитым на несколько строк значением атрибута
version: 1 dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com objectclass:top objectclass:person objectclass:organizationalPerson cn:Barbara Jensen cn:Barbara J Jensen cn:Babs Jensen sn:Jensen uid:bjensen telephonenumber:+1 408 555 1212 description:Babs is a big sailing fan, and travels extensively in sea rch of perfect sailing conditions. title:Product Manager, Rod and Reel Division
Пример 3: Файл, содержащий значение, закодированное base-64
version: 1 dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com objectclass: top objectclass: person objectclass: organizationalPerson cn: Gern Jensen cn: Gern O Jensen sn: Jensen uid: gernj telephonenumber: +1 408 555 1212 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg b3V0IG1vcmUu
Пример 4: Файл, содержащий записи с закодированными значениями атрибутов в UTF-8, включающими языковые теги. В комментариях указывается содержимое закодированных атрибутов и отличительных имён в UTF-8.
version: 1
dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
# dn:: ou=<JapaneseOU>,o=Airius
objectclass: top
objectclass: organizationalUnit
ou:: 5Za25qWt6YOo
# ou:: <JapaneseOU>
ou;lang-ja:: 5Za25qWt6YOo
# ou;lang-ja:: <JapaneseOU>
ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
# ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
ou;lang-en: Sales
description: Japanese office
dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
# dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: rogasawara
mail: [email protected]
givenname;lang-ja:: 44Ot44OJ44OL44O8
# givenname;lang-ja:: <JapaneseGivenname>
sn;lang-ja:: 5bCP56yg5Y6f
# sn;lang-ja:: <JapaneseSn>
cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn;lang-ja:: <JapaneseCn>
title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
# title;lang-ja:: <JapaneseTitle>
preferredlanguage: ja
givenname:: 44Ot44OJ44OL44O8
# givenname:: <JapaneseGivenname>
sn:: 5bCP56yg5Y6f
# sn:: <JapaneseSn>
cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn:: <JapaneseCn>
title:: 5Za25qWt6YOoIOmDqOmVtw==
# title:: <JapaneseTitle>
givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
# givenname;lang-ja;phonetic::
<JapaneseGivenname_in_phonetic_representation_kana>
sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
# sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
# cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
# title;lang-ja;phonetic::
# <JapaneseTitle_in_phonetic_representation_kana>
givenname;lang-en: Rodney
sn;lang-en: Ogasawara
cn;lang-en: Rodney Ogasawara
title;lang-en: Sales, Director
Пример 5: Файл, содержащий ссылку на внешний файл
version: 1 dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com objectclass: top objectclass: person objectclass: organizationalPerson cn: Horatio Jensen cn: Horatio N Jensen sn: Jensen uid: hjensen telephonenumber: +1 408 555 1212 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
Пример 6: Файл, содержащий серию изменений записей с комментариями
version: 1 # Добавление новой записи dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com changetype: add objectclass: top objectclass: person objectclass: organizationalPerson cn: Fiona Jensen sn: Jensen uid: fiona telephonenumber: +1 408 555 1212 jpegphoto:< file:///usr/local/directory/photos/fiona.jpg # Удаление существующей записи dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com changetype: delete # Модификация относительного отличительного имени записи dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com changetype: modrdn newrdn: cn=Paula Jensen deleteoldrdn: 1 # Переименование записи и перемещение всех дочерних по отношению # к ней записей в новое местоположение в дереве каталога # (реализуется только серверами LDAPv3) dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com changetype: modrdn newrdn: ou=Product Development Accountants deleteoldrdn: 0 newsuperior: ou=Accounting, dc=airius, dc=com # Модификация записи: добавление дополнительного значения атрибута # postaladdress, полное удаление атрибута description, замена # значений атрибута telephonenumber двумя новыми значениями # и удаление конкретного значения атрибута facsimiletelephonenumber dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com changetype: modify add: postaladdress postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086 - delete: description - replace: telephonenumber telephonenumber: +1 408 555 1234 telephonenumber: +1 408 555 5678 - delete: facsimiletelephonenumber facsimiletelephonenumber: +1 408 555 9876 - # Модификация записи: замена значений атрибута postaladdress пустым # набором значений (что приводит к удалению данного атрибута), # а также всех значений атрибута description. Имейте ввиду, что # первое действие всегда завершается успешно, а второе завершается # успешно лишь когда у атрибута description имеется хотя бы одно значение. dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com changetype: modify replace: postaladdress - delete: description -
Пример 7: LDIF-файл, содержащий изменение записи с элементом управления
version: 1 # Удаление записи. К данной операции будет присоединён элемент управления LDAPv3 # Tree Delete Control, определённый в [9]. Поле criticality установлено в "true", # а поле controlValue отсутствует, согласно требованиям [9]. dn: ou=Product Development, dc=airius, dc=com control: 1.2.840.113556.1.4.805 true changetype: delete
О безопасности
Принимая в расчёт типичные приложения, использующие каталог в качестве хранилища данных, можно предположить, что LDIF-файл, вероятно, будет содержать конфиденциальные персональные данные. Для защиты конфиденциальности тех лиц, информация о которых содержится в LDIF-файле, должны быть предприняты соответствующие меры.
Поскольку директивы ":<" могут привести к тому, что при обработке LDIF-файла в него может быть включено внешнее содержимое, следует быть осторожным при применении LDIF-файлов из внешних источников. В "троянском" LDIF-файле может быть указан файл с конфиденциальным содержимым, который будет включён в запись каталога, а эту запись можно будет потом несанкционированно считать через LDAP.
LDIF не предоставляет какого-либо метода передачи аутентификационной информации с файлом LDIF. Пользователи файлов LDIF должны сами заботиться о проверке целостности LDIF-файла, полученного из внешнего источника.
Благодарности
Формат обмена данными LDAP был разработан как часть эталонной реализации LDAP Мичиганского университета, разработчики: Tim Howes, Mark Smith и Gordon Good. Частично он основывается на работе, поддерживаемой Национальным научным фондом по гранту № NCR-9416667.
Много полезных предложений сделано членами рабочей группы IETF по дополнениям LDAP. В частности, значительный вклад в этот документ, включая тщательный анализ и пересоставление BNF, сделал Hallvard B. Furuseth из Университета Осло.
Документы
| [1] | Howes, T. and M. Smith, «A MIME Content-Type for Directory Information», RFC 2425, сентябрь 1998 г. |
| [2] | Crocker, D., and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, ноябрь 1997 г. |
| [3] | Wahl, M., Kille, S. and T. Howes, «A String Representation of Distinguished Names», RFC 2253, декабрь 1997 г. |
| [4] | Wahl, M., Howes, T. and S. Kille, «Lightweight Directory Access Protocol (v3)», RFC 2251, июль 1997 г. |
| [5] | Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, ноябрь 1996 г. |
| [6] | Berners-Lee, T., Masinter, L. and M. McCahill, «Uniform Resource Locators (URL)», RFC 1738, декарь 1994 г. |
| [7] | Bradner, S., «Ключевые слова для обозначения уровня требований в RFC», RFC 2119, BCP 14, март 1997 г. |
| [8] | The SLAPD and SLURPD Administrators Guide. University of Michigan, апрель 1996 г. <URL: http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html> |
| [9] | M. P. Armijo, «Tree Delete Control», работы продолжаются. |
Адрес автора
Gordon Good, iPlanet e-commerce Solutions.
150 Network Circle, Mailstop USCA17-201, Santa Clara, CA 95054, USA
Phone: +1 408 276 4351
EMail: [email protected]
Полное заявление авторских прав
Copyright (C) Internet Society (2000). Все права защищены.
Этот документ и его переводы могут быть скопированы и переработаны в другие документы. Производные работы, комментирующие или иным способом поясняющие данный документ, либо оказывающие помощь в его реализации, могут быть подготовлены, скопированы, опубликованы и распространены, целиком или частями, без каких-либо ограничений, при условии, что указанное выше уведомление об авторском праве и этот параграф будут включены во все такие копии и производные работы. Однако, в этот документ как таковой не может быть внесено каких-либо изменений, таких как удаление уведомления об авторских правах или ссылок на Internet Society или другие организации Интернет, за исключением случаев, когда это требуется для разработки стандартов Интернет (при этом должны быть пройдены процедуры получения авторских прав, определённые в стандартах Интернет), либо когда это требуется при переводе на языки, отличные от английского.
Предоставляемые выше ограниченные права являются бессрочными и не подлежат отзыву Internet Society, его наследниками или правопреемниками.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
Признание заслуг
Финансирование функций RFC Editor в настоящий момент обеспечивается Internet Society.
Перевод выполнен участниками проекта. Предложения по улучшению перевода и сообщения об ошибках принимаются на форуме проекта.