stringtranslate.com

Запрос комментариев

Запрос на комментарии ( RFC ) — это публикация из серии основных органов технического развития и установления стандартов Интернета , в первую очередь Инженерной группы Интернета (IETF). [1] [2] RFC создается отдельными лицами или группами инженеров и ученых-компьютерщиков в форме меморандума , описывающего методы, поведение, исследования или инновации, применимые к работе Интернета и подключенных к Интернету систем. Он отправляется либо на рецензирование , либо для передачи новых концепций, информации или, иногда, технического юмора. [3]

IETF принимает некоторые предложения, опубликованные в виде RFC, в качестве интернет-стандартов . Однако многие RFC носят информационный или экспериментальный характер и не являются стандартами. [4] Система RFC была изобретена Стивом Крокером в 1969 году для записи неофициальных заметок о развитии ARPANET . С тех пор RFC стали официальными документами спецификаций Интернета , протоколов связи , процедур и событий. [5] По словам Крокера, эти документы «формируют внутреннюю работу Интернета и сыграли значительную роль в его успехе», но не получили широкой известности за пределами сообщества. [6]

За пределами интернет-сообщества были опубликованы и другие документы, также называемые запросами на комментарии , как, например, в работе федерального правительства США , например, Национальной администрации безопасности дорожного движения . [7]

История

Формат RFC появился в 1969 году как часть плодотворного проекта ARPANET . [6] Сегодня это официальный канал публикации Инженерной рабочей группы Интернета (IETF), Совета по архитектуре Интернета (IAB) и – в некоторой степени – мирового сообщества исследователей компьютерных сетей в целом.

Авторы первых RFC перепечатывали свою работу и распространяли печатные копии среди исследователей ARPA . В отличие от современных RFC, многие из ранних RFC представляли собой фактические запросы на комментарии и имели такое название, чтобы не показаться слишком декларативным и стимулировать обсуждение. [8] [9] RFC оставляет вопросы открытыми и написан в менее формальном стиле. Этот менее формальный стиль теперь типичен для интернет-проектов документов, предшествующего шагу перед утверждением в качестве 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 с федеральным правительством США Интернет-сообщество, действуя от имени IETF, заключило договор с Сетевым отделом Института информационных наук Университета Южной Калифорнии (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, чтобы обсудить потенциальные изменения в модели редактора RFC. Результаты программы были включены в модель редактора RFC (версия 3), определенную в RFC 9280, опубликованном в июне 2022 года. [1] В целом новая модель предназначена для разъяснения обязанностей и процессов определения и реализации политик, связанных с RFC. series и функция редактора 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 ( The Internet Standards Process, Revision 3 ). [21]

Процесс производства RFC отличается от процесса стандартизации официальных организаций по стандартизации, таких как Международная организация по стандартизации (ISO). Эксперты по интернет-технологиям могут подать интернет-проект без поддержки со стороны внешнего учреждения. RFC, посвященные стандартам, публикуются с одобрения IETF и обычно создаются экспертами, участвующими в рабочих группах IETF , которые сначала публикуют черновой вариант в Интернете. Этот подход облегчает первоначальные раунды экспертной оценки до того, как документы созреют в RFC. [22]

Традиция RFC прагматичного, основанного на опыте и постфактум авторства стандартов, осуществляемого отдельными лицами или небольшими рабочими группами, может иметь важные преимущества [ необходимы разъяснения ] по сравнению с более формальным процессом, управляемым комитетами, типичным для ISO и национальных органов по стандартизации. [ нужна цитата ]

В большинстве RFC используется общий набор терминов, таких как «ДОЛЖЕН» и «НЕ РЕКОМЕНДУЕТСЯ» (как определено в RFC 2119 и RFC 8174), расширенная форма Бэкуса-Наура (ABNF) (RFC 5234) в качестве метаязыка и простой текст. форматирование, позволяющее обеспечить единообразие и простоту понимания RFC. [21]

Подсерия

Серия RFC содержит три подсерии документов IETF RFC: BCP, FYI и STD. Best Current Practice (BCP) — это подсерия обязательных RFC IETF, не входящих в список стандартов. «Для вашей информации» (FYI) — это подсерия информационных RFC, продвигаемых IETF, как указано в RFC 1150 (FYI 1). В 2011 году RFC 6360 устарел к вашему сведению 1 и завершил эту подсерию. Стандарт (STD) раньше был третьим и самым высоким уровнем зрелости в треке стандартов IETF, указанном в RFC 2026 (BCP 9). В 2011 году RFC 6410 (новая часть BCP 9) сократил набор стандартов до двух уровней зрелости. [ нужна цитата ]

Потоки

Существует пять потоков RFC: IETF , IRTF , IAB , независимая подача , [23] и редакционная статья . [1] Только IETF создает BCP и RFC по стандартизации. IAB публикует информационные документы, касающиеся политики и архитектуры. IRTF публикует результаты исследований либо в виде информационных документов, либо в виде экспериментов. Независимые материалы публикуются по усмотрению независимого редактора материалов. Документы, не относящиеся к IETF, проверяются IESG на предмет противоречий с работой IETF. IRTF и независимые  RFC обычно содержат соответствующую информацию или эксперименты для Интернета в целом, не противоречащие работе IETF. сравните RFC 4846, RFC 5742 и RFC 5744. [24] [25] Редакционный поток используется для внесения изменений в редакционную политику в серии RFC (см. RFC 9280). [1]

Получение RFC

Официальным источником RFC в Интернете является редактор RFC. Практически любой опубликованный RFC можно получить по URL-адресу вида http://www.rfc-editor.org/rfc/rfc5000.txt, показанному для RFC 5000.

Каждый RFC представляется в виде обычного текста ASCII и публикуется в этой форме, но может быть доступен и в других форматах .

Для быстрого доступа к метаданным RFC, включая аннотацию, ключевые слова, автора(ов), дату публикации, опечатки, статус и особенно более поздние обновления, сайт редактора RFC предлагает форму поиска со множеством функций. Перенаправление устанавливает некоторые эффективные параметры, например: rfc:5000. [4]

Официальный международный стандартный серийный номер (ISSN) серии RFC — 2070–1721. [16]

Положение дел

Не все RFC являются стандартами. [26] [27] Каждому RFC присвоено обозначение в зависимости от статуса в процессе стандартизации Интернета. Этот статус может быть одним из следующих: «Информационный» , «Экспериментальный» , «Лучшая текущая практика» , «Стандартный трек » или «Исторический» .

После отправки, принятия и публикации RFC не может быть изменен. Могут быть представлены ошибки, которые публикуются отдельно. Более существенные изменения требуют новой подачи, которая получит новый серийный номер. [28]

Стандарты

Документы, соответствующие стандартам, далее подразделяются на предлагаемые стандарты и документы Интернет-стандартов . [29]

Только IETF, представленный Руководящей группой по разработке Интернета (IESG), может утверждать RFC , отслеживающие стандарты .

Если RFC становится стандартом Интернета (STD), ему присваивается номер STD, но сохраняется номер RFC. Полный список интернет-стандартов — это Официальные стандарты интернет-протоколов. Ранее STD 1 использовался для сохранения моментального снимка списка. [30]

При обновлении интернет-стандарта его номер 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 может быть переведен в категорию стандартов, если он станет популярным и будет хорошо работать. [31]

Лучшая текущая практика

В подсерии Best Current Practice собраны административные документы и другие тексты, которые считаются официальными правилами и не только информативны , но и не затрагивают передаваемые по телевидению данные . Граница между треком стандартов и BCP часто нечеткая. Если документ влияет только на процесс стандартизации Интернета, например, BCP 9, [32] или администрирование IETF, то это явно BCP. Если он определяет только правила и положения для реестров Управления по присвоению номеров Интернета (IANA), это менее ясно; большинство из этих документов являются ППГ, но некоторые уже находятся на стадии разработки стандартов.

Серия BCP также включает технические рекомендации по применению стандартов Интернета; например, рекомендация использовать фильтрацию источников, чтобы затруднить DoS-атаки (RFC 2827: « Фильтрация сетевого входа: борьба с атаками типа «отказ в обслуживании», которые используют подмену IP-адреса источника ») — это BCP 38.

Исторический

Исторический RFC — это тот, в котором технология , определенная RFC, больше не рекомендуется для использования, что отличается от заголовка «Устарело» в заменяющем RFC. Например, сам RFC 821 ( SMTP ) устарел из-за различных новых RFC, но сам SMTP по-прежнему является «современной технологией», поэтому он не находится в «историческом» статусе. [33] Однако, поскольку версия BGP 4 полностью заменила более ранние версии BGP, RFC, описывающие эти более ранние версии, такие как RFC 1267, были признаны историческими.

Неизвестный

Статус «неизвестно» используется для некоторых очень старых RFC, в которых неясно, какой статус получил бы документ, если бы он был опубликован сегодня. Некоторые из этих RFC сегодня вообще не будут опубликованы; Ранние RFC часто представляли собой просто запрос на комментарии, не предназначенный для указания протокола, административной процедуры или чего-либо еще, для чего сегодня используется серия RFC. [34]

Авторские права

Общее правило заключается в том, что оригинальные авторы (или их работодатели, если это предусмотрено условиями их работы) сохраняют авторские права, если только они не осуществят явную передачу своих прав. [35]

Независимый орган, IETF Trust, владеет авторскими правами на некоторые RFC, а на все остальные авторы предоставляют лицензию, позволяющую воспроизводить RFC. [36] Internet Society упоминается во многих RFC до RFC4714 как владелец авторских прав, но оно передало свои права IETF Trust. [37]

Примечания

Смотрите также

Рекомендации

  1. ^ abcd Сент-Андре, Питер (июнь 2022 г.). Модель редактора RFC (версия 3). IETF . дои : 10.17487/RFC9280 . RFC 9280. Серия запросов на комментарии (RFC) — это архивная серия, посвященная документированию технических спецификаций Интернета, ...
  2. ^ "RFC" . IETF . Проверено 5 ноября 2023 г.
  3. ↑ Вайцман, Дэвид (1 апреля 1990 г.). Стандарт передачи IP-дейтаграмм на авиационных носителях. IETF . дои : 10.17487/RFC1149 . РФК 1149 . Проверено 29 марта 2017 г.
  4. ^ аб Хуитема, Кристиан ; Постел, Джон ; Крокер, Стив (апрель 1995 г.). Не все RFC являются стандартами. IETF . дои : 10.17487/RFC1796 . РФК 1796 . Проверено 15 мая 2018 г.
  5. ^ «RFC, Интернет-запрос комментариев» . Livinginternet.com . Проверено 3 апреля 2012 г.
  6. ^ ab «Стивен Д. Крокер, Как в Интернете появились свои правила, The New York Times, 6 апреля 2009 г.» . Нью-Йорк Таймс . 7 апреля 2009 года . Проверено 3 апреля 2012 г.
  7. ^ «Уведомление и запрос комментариев». Федеральный реестр . 16 января 2018 г.
  8. ^ Хафнер, Кэти; Лион, Мэтью (1996). Где волшебники ложатся спать допоздна: Истоки Интернета . Книга Пробный камень. Саймон и Шустер. ISBN 978-0-684-81201-4.
  9. ↑ Мец, Кейд (18 мая 2012 г.). «Знакомьтесь, человек, который изобрел инструкции для Интернета». Проводной . Проверено 18 декабря 2018 г.
  10. ↑ Крокер, Стив (7 апреля 1969 г.). RFC 1. doi : 10.17487/RFC0001 . РФК 1.
  11. ^ Элизабет Дж. Фейнлер (июль – сентябрь 2010 г.). «Сетевой информационный центр и его архивы». Анналы истории вычислительной техники . 32 (3): 83–89. дои : 10.1109/MAHC.2010.54. S2CID  206443021.
  12. ^ Лесли Дэйгл (март 2010 г.). «Редактор RFC в переходный период: прошлое, настоящее и будущее». Журнал Интернет-протокола . Том. 13, нет. 1. Системы Сиско . Проверено 17 августа 2011 г.
  13. ^ Дэйгл, Лесли (июль 2007 г.). Серия RFC и редактор RFC. IETF . дои : 10.17487/RFC4844 . РФК 4844.
  14. ^ Колкман, Олаф (август 2009 г.). Модель редактора RFC (версия 1). IETF . дои : 10.17487/RFC5620 . РФК 5620.
  15. ^ Колкман, Олаф; Халперн, Джоэл (июнь 2012 г.). Модель редактора RFC (версия 2). IETF . дои : 10.17487/RFC6635 . РФК 6635.
  16. ^ аб Дейгл, Лесли; Колкман, Олаф (декабрь 2009 г.). Потоки RFC, заголовки и шаблоны. IETF . дои : 10.17487/RFC5741 . РФК 5741.
  17. ↑ Гленн Ковак (7 января 2010 г.). «Объявление о переходе редактора RFC» . Архивировано из оригинала 29 июня 2011 года.
  18. ^ «Редактор серии RFC и реорганизация серии» . Проверено 5 апреля 2013 г.
  19. ^ «Алексис Росси назначен редактором-консультантом серии RFC» . Проверено 19 августа 2023 г.
  20. ^ «Часто задаваемые вопросы по изменению формата RFC» .
  21. ^ ab «Индекс RFC». Редактор RFC. 25 мая 2008 года . Проверено 26 мая 2008 г.
  22. ^ Рекомендации и процедуры рабочей группы IETF. дои : 10.17487/RFC2418 . РФК 2418.
  23. ^ «Независимые материалы». Редактор RFC . Проверено 5 января 2018 г.
  24. ^ Кленсин, Джон; Талер, Дэвид (июль 2007 г.). Независимые отправки в редактор RFC. ИАБ . дои : 10.17487/RFC4846 . РФК 4846.>
  25. ^ Альвестранд, Харальд; Хаусли, Расс (декабрь 2009 г.). Процедуры IESG для обработки независимых материалов и потоков IRTF. IETF . дои : 10.17487/RFC5742 . РФК 5742.
  26. ^ «Все ли RFC являются документами интернет-стандартов?». Редактор RFC . Проверено 16 марта 2018 г.
  27. ^ Хуитема, Кристиан ; Постел, Джон ; Крокер, Стив (апрель 1995 г.). Не все RFC являются стандартами. IETF . дои : 10.17487/RFC1796 . RFC 1796. ... каждый RFC имеет статус…: Информационный, Экспериментальный или Стандартный (Предлагаемый стандарт, Проект стандарта, Интернет-стандарт) или Исторический.
  28. Рианна Ноттингем, Марк (31 июля 2018 г.). «Как читать RFC» . Проверено 18 сентября 2023 г. RFC — это архивная серия документов; они не могут измениться[.]
  29. ^ Хаусли, Рассел; Крокер, Дэйв; Бургер, Эрик (октябрь 2011 г.). Сокращение системы стандартов до двух уровней зрелости. IETF . дои : 10.17487/RFC6410 . РФК 6410.
  30. ^ Упразднение сводного документа «Стандарты официальных протоколов Интернета». дои : 10.17487/RFC7100 . РФК 7100.
  31. ^ «7.5. Информационные и экспериментальные RFC», Дао IETF , получено 26 ноября 2017 г.
  32. ^ Брэднер, Скотт О. (октябрь 1996 г.). Процесс стандартизации Интернета – Редакция 3. IETF . ППГ 9 . Проверено 25 октября 2017 г.
  33. ^ «Заявление IESG о признании RFC историческими» . IETF. 20 июля 2014 года . Проверено 14 апреля 2016 г.
  34. ^ Стандарты IETF Написано участниками ISC, Консорциумом интернет-систем , 10 сентября 2021 г., заархивировано из оригинала 5 апреля 2022 г. , получено 11 апреля 2022 г. Многие из ранних документов RFC имеют статус «неизвестно» , поскольку они пришли из давних времен. -ушла эпоха, когда RFC на самом деле был просто запросом комментариев.
  35. ^ «Воспроизведение RFC». Траст IETF . Проверено 12 августа 2021 г.
  36. ^ Брэднер, Скотт; Контрерас, Хорхе (ноябрь 2008 г.). Права участников предоставляют IETF Trust. IETF . дои : 10.17487/RFC5378 . РФК 5378.
  37. ^ «Воспроизведение RFC». Траст IETF . Проверено 13 августа 2021 г.

Внешние ссылки