Запрос на комментарии ( RFC ) — это публикация в серии основных технических органов по разработке и стандартизации Интернета , наиболее известным из которых является Internet Engineering Task Force (IETF). [1] [2] RFC создается отдельными лицами или группами инженеров и компьютерных специалистов в форме меморандума, описывающего методы, поведение, исследования или инновации, применимые к работе Интернета и подключенных к Интернету систем. Он представляется либо для рецензирования, либо для передачи новых концепций, информации или, иногда, инженерного юмора. [3]
IETF принимает некоторые предложения, опубликованные как RFC, в качестве стандартов Интернета . Однако многие RFC носят информационный или экспериментальный характер и не являются стандартами. [4] Система RFC была изобретена Стивом Крокером в 1969 году для записи неофициальных заметок о разработке ARPANET . С тех пор RFC стали официальными документами спецификаций Интернета , протоколов связи , процедур и событий. [5] По словам Крокера, документы «формируют внутреннюю работу Интернета и сыграли значительную роль в его успехе», но не получили широкой известности за пределами сообщества. [6]
За пределами интернет-сообщества были опубликованы и другие документы, также называемые запросами на комментарии , как, например, в работе федерального правительства США , например, Национальной администрации безопасности дорожного движения . [7]
Формат RFC был создан в 1969 году в рамках основополагающего проекта ARPANET . [6] Сегодня это официальный канал публикации для Internet Engineering Task Force (IETF), Internet Architecture Board (IAB) и — в некоторой степени — для мирового сообщества исследователей компьютерных сетей в целом.
Авторы первых RFC печатали свои работы и распространяли печатные копии среди исследователей ARPA . В отличие от современных RFC, многие из ранних RFC были фактическими запросами на комментарии и были названы так, чтобы не звучать слишком декларативно и поощрять обсуждение. [8] [9] RFC оставляет вопросы открытыми и написан в менее формальном стиле. Этот менее формальный стиль сейчас типичен для документов Internet Draft , предшествующего этапу утверждения в качестве RFC.
В декабре 1969 года исследователи начали распространять новые RFC через недавно запущенную сеть ARPANET. RFC 1, озаглавленный «Host Software», был написан Стивом Крокером из Калифорнийского университета в Лос-Анджелесе (UCLA) и опубликован 7 апреля 1969 года. [10] Хотя RFC был написан Стивом Крокером, он появился в результате раннего обсуждения рабочей группы между Стивом Крокером, Стивом Карром и Джеффом Рулифсоном .
ВRFC 3, который впервые определил серию RFC, Крокер начал приписывать серию RFC Сетевой рабочей группе. Вместо того, чтобы быть формальным комитетом, это было свободное объединение исследователей, заинтересованных в проекте ARPANET. По сути, оно включало всех, кто хотел присоединиться к встречам и обсуждениям проекта.
Многие из последующих RFC 1970-х годов также пришли из UCLA, потому что UCLA является одним из первых процессоров интерфейсных сообщений (IMP) в ARPANET. Исследовательский центр расширения (ARC) в Стэнфордском исследовательском институте , которым руководил Дуглас Энгельбарт , является еще одним из четырех первых узлов ARPANET и источником ранних RFC. ARC стал первым сетевым информационным центром ( InterNIC ), которым управляла Элизабет Дж. Файнлер для распространения RFC вместе с другой сетевой информацией. [11]
С 1969 по 1998 год Джон Постел был редактором RFC . После его смерти в 1998 году его некролог был опубликован под номером RFC 2468.
После истечения срока действия первоначального контракта ARPANET с федеральным правительством США Internet Society, действуя от имени IETF, заключило контракт с сетевым подразделением Института информационных наук (ISI) Университета Южной Калифорнии (USC ), чтобы взять на себя обязанности по редактированию и публикации под руководством IAB. Сэнди Джиноза присоединился к USC/ISI в 1999 году для работы над редактированием RFC, а Элис Хагенс — в 2005 году. [12] Боб Брейден взял на себя роль руководителя проекта RFC, в то время как Джойс К. Рейнольдс продолжала быть частью команды до 13 октября 2006 года.
В июле 2007 года были определены потоки RFC, чтобы можно было разделить обязанности по редактированию. Документы IETF поступали от рабочих групп IETF или заявок, спонсируемых директором области IETF из Руководящей группы по инжинирингу Интернета . IAB может публиковать свои собственные документы. Исследовательский поток документов поступает от Целевой группы по исследованиям Интернета (IRTF), а независимый поток — из других внешних источников. [13] Новая модель была предложена в 2008 году, улучшена и опубликована в августе 2009 года, разделив задачу на несколько ролей, [14] включая Консультативную группу по сериям RFC (RSAG). Модель была обновлена в 2012 году. [15] Потоки также были улучшены в декабре 2009 года, и для их стиля были определены стандарты. [16]
В январе 2010 года функция редактора RFC была передана подрядчику, Association Management Solutions, а Гленн Ковак стал временным редактором серии. [17] В конце 2011 года Хизер Фланаган была нанята в качестве постоянного редактора серии RFC (RSE). В то же время был создан Комитет по надзору за серией RFC (RSOC). [18]
В 2020 году IAB созвал программу RFC Editor Future Development для обсуждения возможных изменений в модели RFC Editor. Результаты программы включали модель RFC Editor (версия 3), как определено в RFC 9280, опубликованном в июне 2022 года. [1] В целом, новая модель предназначена для уточнения обязанностей и процессов для определения и внедрения политик, связанных с серией RFC и функцией редактора RFC. Изменения в новой модели включали создание должности редактора-консультанта RFC, рабочей группы серии RFC (RSWG) и Совета по утверждению серии RFC (RSAB). Он также создал новый редакционный поток для серии RFC и завершил RSOC. Роль RSE была изменена на редактора-консультанта RFC (RSCE). В сентябре 2022 года на эту должность был назначен Алексис Росси. [19]
Запросы на комментарии изначально создавались в непереформатируемом текстовом формате. В августе 2019 года формат был изменен, чтобы новые документы можно было оптимально просматривать на устройствах с различными размерами дисплеев. [20]
Редактор RFC присваивает каждому RFC порядковый номер . После присвоения номера и публикации RFC никогда не отменяется и не изменяется; если документ требует внесения поправок, авторы публикуют пересмотренный документ. Поэтому некоторые RFC заменяют другие; заменяемые RFC считаются устаревшими , устаревшими или устаревшими из-за заменяющего RFC. Вместе сериализованные RFC составляют непрерывную историческую запись эволюции стандартов и практик Интернета. Процесс RFC задокументирован в RFC 2026 ( Процесс разработки стандартов Интернета, редакция 3 ). [21]
Процесс производства RFC отличается от процесса стандартизации формальных организаций по стандартизации, таких как Международная организация по стандартизации (ISO). Эксперты по интернет-технологиям могут представить интернет-проект без поддержки внешнего учреждения. Стандартизированные RFC публикуются с одобрения IETF и обычно разрабатываются экспертами, участвующими в рабочих группах IETF , которые сначала публикуют интернет-проект. Такой подход облегчает начальные раунды рецензирования до того, как документы превратятся в RFC. [22]
Традиция RFC, предполагающая прагматичную, основанную на опыте и постфактум разработанную стандартную разработку отдельными лицами или небольшими рабочими группами, может иметь важные преимущества [ необходимо разъяснение ] по сравнению с более формальным процессом, основанным на комитетах, типичным для ISO и национальных органов по стандартизации. [23]
Большинство RFC используют общий набор терминов, таких как «ОБЯЗАТЕЛЬНО» и «НЕ РЕКОМЕНДУЕТСЯ» (как определено в RFC 2119 и 8174), расширенную форму Бэкуса-Наура (ABNF) ( RFC 5234) в качестве метаязыка и простое текстовое форматирование, чтобы сохранить согласованность и простоту понимания RFC. [21]
Серия RFC содержит три подсерии для RFC IETF : BCP, FYI и STD. Best Current Practice (BCP) — это подсерия обязательных RFC IETF, не относящихся к стандартам. For Your Information (FYI) — это подсерия информационных RFC, продвигаемых IETF, как указано в RFC 1150 (FYI 1). В 2011 году RFC 6360 отменил FYI 1 и завершил эту подсерию. Standard (STD) раньше был третьим и наивысшим уровнем зрелости стандартного трека IETF, указанного в RFC 2026 (BCP 9). В 2011 году RFC 6410 (новая часть BCP 9) сократил трек стандартов до двух уровней зрелости. [ необходима цитата ]
Существует пять потоков RFC: IETF , IRTF , IAB , независимая подача , [24] и редакционный . [1] Только IETF создает BCP и RFC на треке стандартов. IAB публикует информационные документы, касающиеся политики или архитектуры. IRTF публикует результаты исследований, либо в виде информационных документов, либо в виде экспериментов. Независимые заявки публикуются по усмотрению редактора независимых заявок. Документы, не относящиеся к IETF, проверяются IESG на предмет конфликтов с работой IETF. IRTF и независимые RFC обычно содержат соответствующую информацию или эксперименты для Интернета в целом, не конфликтующие с работой IETF. сравните RFC 4846, 5742 и 5744. [25] [26] Редакционный поток используется для внесения изменений в редакционную политику в серии RFC (см. RFC 9280). [1]
Официальным источником RFC в World Wide Web является RFC Datatracker. Почти любой опубликованный RFC можно получить через URL-адрес вида https://datatracker.ietf.org/doc/html/rfc5000, показанный для RFC 5000.
Каждый RFC представляется в виде простого текста ASCII и публикуется в этой форме, но может быть доступен и в других форматах .
Для легкого доступа к метаданным RFC, включая аннотацию, ключевые слова, автора(ов), дату публикации, исправления, статус и особенно более поздние обновления, сайт редактора RFC предлагает форму поиска со множеством функций. Перенаправление устанавливает некоторые эффективные параметры, например: rfc:5000. [4]
Официальный международный стандартный серийный номер (ISSN) серии RFC — 2070-1721. [16]
Не все RFC являются стандартами. [27] [28] Каждому RFC присваивается обозначение в соответствии со статусом в процессе стандартизации Интернета. Этот статус может быть одним из следующих: Информационный , Экспериментальный , Лучшая текущая практика , Стандарты трека или Исторический .
После отправки, принятия и публикации RFC не может быть изменен. Могут быть отправлены исправления, которые публикуются отдельно. Более существенные изменения требуют нового представления, которому будет присвоен новый серийный номер. [29]
Документы по стандартам далее подразделяются на предлагаемые стандарты и документы по стандартам Интернета . [30]
Только IETF, представленная Руководящей группой по инжинирингу Интернета (IESG), может утверждать RFC , отслеживающие стандарты .
Если RFC становится стандартом Интернета (STD), ему присваивается номер STD, но он сохраняет свой номер RFC. Окончательный список стандартов Интернета — это официальные стандарты протоколов Интернета. Ранее STD 1 использовался для поддержания снимка списка. [31]
При обновлении стандарта Интернета его номер STD остается прежним, теперь ссылаясь на новый RFC или набор RFC. Определенный стандарт Интернета, STD n , может быть RFC x и y в определенное время, но позже тот же стандарт может быть обновлен до RFC z вместо этого. Например, в 2007 году RFC 3700 был стандартом Интернета — STD 1 — а в мае 2008 года он был заменен на RFC 5000, поэтому RFC 3700 изменился на Historic , RFC 5000 стал стандартом Интернета, и с мая 2008 года [обновлять]STD 1 стал RFC 5000. с декабря 2013 года RFC 5000 заменен на RFC 7100, обновив RFC 2026, чтобы больше не использовать STD 1.[обновлять]
(Текущие передовые практики работают аналогичным образом; BCP n относится к определенному RFC или набору RFC, но какой RFC или RFC могут со временем меняться).
Информационный RFC может быть чем угодно, от шуток на 1 апреля до широко признанных основных RFC, таких как Структура и делегирование системы доменных имен ( RFC 1591). Некоторые информационные RFC сформировали подсерию FYI .
Экспериментальный RFC может быть документом IETF или индивидуальным представлением редактору RFC. Проект считается экспериментальным, если неясно, будет ли предложение работать так, как задумано, или неясно, будет ли оно широко принято. Экспериментальный RFC может быть переведен в стандартный режим, если он станет популярным и будет хорошо работать. [32]
Подсерия Best Current Practice собирает административные документы и другие тексты, которые считаются официальными правилами и не только информационными , но и не влияющими на данные, передаваемые по проводам . Граница между стандартами и BCP часто неясна. Если документ влияет только на процесс стандартов Интернета, как BCP 9, [33] или администрирование IETF, то это явно BCP. Если он определяет только правила и положения для реестров Управления по присвоению номеров Интернета (IANA), то это менее ясно; большинство этих документов являются BCP, но некоторые из них находятся на пути стандартов.
В серии BCP также содержатся технические рекомендации по применению стандартов Интернета; например, рекомендация использовать фильтрацию источника для затруднения DoS -атак ( RFC 2827: « Фильтрация входящего трафика в сеть: борьба с атаками типа «отказ в обслуживании», использующими подмену IP-адреса источника ») содержится в BCP 38.
Исторический RFC — это тот, который указывает на то, что технология, определенная RFC, больше не рекомендуется для использования, что отличается от заголовка «Устаревшие» в заменяющем RFC. Например, сам RFC 821 ( SMTP ) устарел из-за различных более новых RFC, но сам SMTP по-прежнему является «текущей технологией», поэтому он не находится в статусе «Исторический». [34] Однако, поскольку версия BGP 4 полностью заменила более ранние версии BGP, RFC, описывающие эти более ранние версии, такие как RFC 1267, были обозначены как исторические.
Статус unknown используется для некоторых очень старых RFC, где неясно, какой статус документ получил бы, если бы был опубликован сегодня. Некоторые из этих RFC сегодня вообще не были бы опубликованы; ранний RFC часто был именно этим: простым запросом на комментарии, не предназначенным для указания протокола, административной процедуры или чего-либо еще, для чего серия RFC используется сегодня. [35]
Общее правило заключается в том, что оригинальные авторы (или их работодатели, если это предусмотрено условиями их трудоустройства) сохраняют авторские права, если только они не совершают явную передачу своих прав. [36]
Независимый орган, IETF Trust, владеет авторскими правами на некоторые RFC, а для всех остальных ему авторы предоставляют лицензию, которая позволяет ему воспроизводить RFC. [37] Internet Society упоминается во многих RFC до RFC4714 как владелец авторских прав, но он передал свои права IETF Trust. [38]
Серия Request for Comments (RFC) — это архивная серия, посвященная документированию технических спецификаций Интернета, ...
... каждый RFC имеет статус…: информационный, экспериментальный или стандартный (предложенный стандарт, черновик стандарта, стандарт Интернета) или исторический.
RFC — это архивная серия документов; они не могут изменяться[.]
Многие из ранних документов RFC имеют статус «неизвестно», поскольку они относятся к давно ушедшей эпохе, когда RFC на самом деле был просто запросом на комментарии.
RFC ID (P892) (см. использование )