Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Чтобы узнать о процессе в Википедии, см. Википедия: запросы на комментарии .

Запрос на комментарии ( RFC ) является публикация от Internet Society (ISOC) и связанных с ним органов, и прежде всего в Engineering Task Force Интернет (IETF), основные технические разработки и органами , устанавливающими стандарты для Интернета .

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

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

История [ править ]

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

Авторы первого типа RFC написали свою работу и распространили бумажные копии среди исследователей ARPA . В отличие от современных RFC, многие из ранних RFC были фактическими запросами на комментарии и были названы так, чтобы не звучать слишком декларативно и стимулировать обсуждение. [6] [7] RFC оставляет вопросы открытыми и написан в менее формальном стиле. Этот менее формальный стиль теперь типичен для Интернет-проектов документов, предшествующий этапу до утверждения в качестве RFC.

В декабре 1969 года исследователи начали распространять новые RFC через только что действующую сеть ARPANET. RFC  1, названный «Host Software», был написан Стивом Крокером из Калифорнийского университета в Лос-Анджелесе (UCLA) и опубликован 7 апреля 1969 года. [8] Несмотря на то, что он был написан Стивом Крокером, RFC возник на ранней стадии развития. обсуждение в рабочей группе между Стивом Крокером, Стивом Карром и Джеффом Рулифсоном .

В RFC 3 , который первым определил серию RFC, Крокер начал приписывать серию RFC Сетевой рабочей группе. Это был не формальный комитет, а свободная ассоциация исследователей, заинтересованных в проекте ARPANET. Фактически, в него входили все, кто хотел присоединиться к собраниям и обсуждениям проекта.

Многие из последующих RFC 1970-х годов также пришли из UCLA, потому что UCLA является одним из первых процессоров интерфейсных сообщений (IMP) в ARPANET. Исследовательский центр усиливающая (ARC) в Стэнфордском исследовательском институте , режиссер Дуглас Энгельбарт , является еще одним из четырех первых , что были ARPANET узлы и источник ранних РЛК. ARC стал первым сетевым информационным центром ( InterNIC ), которым управляла Элизабет Дж. Фейнлер, который распространял RFC вместе с другой сетевой информацией. [9] С 1969 по 1998 год Джон Постел был редактором RFC.. После его смерти в 1998 году его некролог был опубликован как RFC 2468 .

После истечения срока действия первоначального контракта ARPANET с федеральным правительством США Internet Society, действуя от имени IETF, заключила договор с Сетевым отделом Института информационных наук (ISI) Университета Южной Калифорнии (USC) на редактирование и ответственность за публикацию под руководством IAB. Сэнди Гиноза присоединилась к USC / ISI в 1999 году для работы над редактированием RFC, а Элис Хейгенс - в 2005. [10] Боб Брейден взял на себя роль руководителя проекта RFC, а Джойс К. Рейнольдс продолжала быть частью команды до 13 октября. 2006 г.

В июле 2007 года были определены потоки RFC, чтобы можно было разделить обязанности по редактированию. Документы IETF исходили от рабочих групп IETF или при поддержке регионального директора IETF из Руководящей группы инженеров Интернета . IAB может публиковать собственные документы. Исследовательский поток документов поступает от Целевой группы по исследованиям Интернета (IRTF), а независимый поток - из других внешних источников. [11] Новая модель была предложена в 2008 году, доработана и опубликована в августе 2009 года, разделив задачу на несколько ролей, [12] включая Консультативную группу RFC Series (RSAG). Модель была обновлена ​​в 2012 году. [13]В декабре 2009 года потоки также были усовершенствованы, и для их стиля были определены стандарты. [14] В январе 2010 года функция редактора RFC была передана подрядчику, Association Management Solutions , а Гленн Ковак исполнял обязанности временного редактора серии. [15] В конце 2011 года Хизер Фланаган была нанята в качестве постоянного редактора RFC Series. Также в то время был создан Комитет по надзору за сериями RFC (RSOC). [16]

Запросы на комментарии изначально создавались в текстовом формате, не допускающем перекомпоновки . В августе 2019 года формат был изменен, чтобы новые документы можно было оптимально просматривать на устройствах с различным размером экрана. [17]

Производство и управление версиями [ править ]

Редактор RFC присваивает каждому RFC серийный номер . После присвоения номера и публикации RFC никогда не отменяется и не изменяется; если документ требует внесения изменений, авторы публикуют исправленный документ. Следовательно, одни RFC заменяют другие; замененные RFC считаются устаревшими , устаревшими или устаревшими в соответствии с заменяющим RFC. Вместе сериализованные RFC составляют непрерывный исторический отчет об эволюции Интернет-стандартов и практик. Процесс RFC задокументирован в RFC 2026 ( The Internet Standards Process, Revision 3 ). [18]

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

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

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

Подсерия [ править ]

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

Потоки [ править ]

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

Получение RFC [ править ]

RFC 2046 Типы носителей, ноябрь 1996 г. A. Собранная грамматика .................................... 431. Введение Первый документ в этом наборе, RFC 2045, определяет номер заголовка. поля, включая Content-Type. Поле Content-Type используется для указать природу данных в теле объекта MIME с помощью предоставляя идентификаторы типа и подтипа носителя, а также предоставляя вспомогательные информация, которая может потребоваться для определенных типов носителей. После
RFC  2046 , который определяет тип MIME text / plain , сам по себе является обычным текстом.
Начало страницы 3

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

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

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

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

Статус [ править ]

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

Каждый RFC статичен; если документ изменен, он отправляется снова и получает новый номер RFC. [ необходима цитата ]

Standards Track [ править ]

Основная статья: Интернет-стандарт § Интернет-стандарты

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

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

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

Когда Интернет-стандарт обновляется, его номер STD остается прежним, теперь он относится к новому RFC или набору RFC. Данный стандарт Интернета, STD n , может быть RFC x и y в данный момент времени, но позже этот же стандарт может быть обновлен до RFC z . Например, в 2007 году RFC 3700 был стандартом Интернета - STD 1, а в мае 2008 года он был заменен на RFC 5000 , поэтому RFC 3700 был изменен на Исторический , RFC 5000 стал стандартом Интернета, а с мая 2008 года STD 1 стал RFC 5000. . с декабря 2013 года RFC 5000 заменен на RFC 7100 , обновление RFC 2026, чтобы больше не использовать STD 1.

(Best Current Practices работают аналогичным образом; BCP n относится к определенному RFC или набору RFC, но какие RFC или RFC могут меняться со временем).

Информационный [ править ]

Информационный RFC может быть почти ничего от 1 апреля шутки в широко признанном основной РЛК , как система доменных имен Структура и делегирование ( RFC 1591 ). Некоторые информационные RFC сформировали подсерию FYI .

Экспериментальный [ править ]

Экспериментальный RFC может быть документом IETF или физическое лицо подчинение "RFC Editor. Проект считается экспериментальным, если неясно, будет ли предложение работать так, как задумано, или неясно, будет ли оно широко принято. Экспериментальный RFC может быть повышен до уровня стандартов, если он станет популярным и хорошо работает. [24]

Наилучшая текущая практика [ править ]

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

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

Исторический [ править ]

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

Неизвестно [ править ]

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

См. Также [ править ]

  • День дурака RFC
  • Лучшая текущая практика
  • Заметка об эксперименте в Интернете
  • Список RFC

Ссылки [ править ]

  1. ^ Waitzman, Дэвид (1 апреля 1990). Стандарт передачи дейтаграмм IP на авианосцах . IETF . DOI : 10,17487 / RFC1149 . RFC 1149 . Проверено 29 марта 2017 года .
  2. ^ Huitema, Кристиан ; Постел, Джон ; Крокер, Стив (апрель 1995 г.). Не все RFC являются стандартами . IETF . DOI : 10,17487 / RFC1796 . RFC 1796 . Проверено 15 мая 2018 года .
  3. ^ "RFC, Интернет-запрос комментариев" . Livinginternet.com . Проверено 3 апреля 2012 года .
  4. ^ a b "Стивен Д. Крокер, Как Интернет получил свои правила , Нью-Йорк Таймс, 6 апреля 2009 г." . Nytimes.com. 7 апреля 2009 . Проверено 3 апреля 2012 года .
  5. ^ Уведомление и запрос комментариев в Федеральном реестре (16 января 2018 г.).
  6. ^ Хафнер, Кэти; Лион, Мэтью (1996). Где мастера не ложатся спать: истоки Интернета.
  7. ^ «Познакомьтесь с человеком, который изобрел инструкции для Интернета» . Проводной . 18 мая 2012 . Проверено 18 декабря 2018 года .
  8. ↑ Crocker, Steve (7 апреля 1969 г.). «RFC 1» . 
  9. ↑ Элизабет Дж. Файнлер (июль – сентябрь 2010 г.). «Сетевой информационный центр и его архивы». Анналы истории вычислительной техники . 32 (3): 83–89. DOI : 10.1109 / MAHC.2010.54 .
  10. ^ Лесли Дейгл (март 2010). «Редактор RFC в переходный период: прошлое, настоящее и будущее» . Журнал Интернет-протокола . 13 (1). Cisco Systems . Проверено 17 августа 2011 года .
  11. ^ Дейгл, Лесли (июль 2007 г.). Серия RFC и редактор RFC . IETF . DOI : 10,17487 / RFC4844 . RFC 4844 .
  12. ^ Kolkman, Олаф (август 2009). Модель редактора RFC (версия 1) . IETF . DOI : 10,17487 / RFC5620 . RFC 5620 .
  13. ^ Колкман, Олаф; Халперн, Джоэл (июнь 2012 г.). Модель редактора RFC (версия 2) . IETF . DOI : 10,17487 / RFC6635 . RFC 6635 .
  14. ^ а б Дейгл, Лесли; Колкман, Олаф (декабрь 2009 г.). RFC-потоки, заголовки и шаблоны . IETF . DOI : 10,17487 / RFC5741 . RFC 5741 .
  15. ^ Гленн Kowack (7 января 2010). "Объявление о переходе редактора RFC" . Проверено 7 августа 2011 года .
  16. ^ Редактор RFC. «Редактор серии RFC и реорганизация серии» . Проверено 5 апреля 2013 года .
  17. ^ Часто задаваемые вопросы об изменении формата RFC
  18. ^ a b " Индекс RFC " . Редактор RFC. 25 мая 2008 . Проверено 26 мая 2008 года .
  19. ^ «Независимые представления» . Редактор RFC . Проверено 5 января 2018 года .
  20. ^ "Все ли документы Интернет-стандартов RFC?" . Редактор RFC . Проверено 16 марта 2018 года .
  21. ^ Huitema, Кристиан ; Постел, Джон ; Крокер, Стив (апрель 1995 г.). Не все RFC являются стандартами . IETF . DOI : 10,17487 / RFC1796 . RFC 1796 . ... каждый RFC имеет статус…: информационный, экспериментальный или стандартный (предлагаемый стандарт, проект стандарта, интернет-стандарт) или исторический.
  22. ^ Хаусли, Рассел; Крокер, Дэйв; Бургер, Эрик (октябрь 2011 г.). Сокращение трека стандартов до двух уровней зрелости . IETF . DOI : 10,17487 / RFC6410 . RFC 6410 .
  23. ^ RFC 7100 Уничтожение "Официальных стандартов протокола Интернета".
  24. ^ "7.5. Информационные и экспериментальные RFC" , The Tao of IETF , получено 26 ноября 2017 г.
  25. ^ Бреднер, Скотт О. (октябрь 1996). Процесс стандартизации Интернета - Редакция 3 . IETF . ПП 9 . Проверено 25 октября 2017 года .
  26. ^ «Заявление IESG об обозначении RFC как исторических» . IETF. 20 июля 2014 . Проверено 14 апреля 2016 года .

Внешние ссылки [ править ]

  • Редактор RFC
  • База данных RFC
  • RFC Errata
  • RFC Часто задаваемые вопросы
  • Индекс RFC (текст)
  • Официальные стандарты интернет-протокола
  • Страница RFC IETF
  • Индекс RFC (HTML) В тексте каждого RFC также упоминается, какие другие RFC «обновляет» или «обновляет».