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

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

Запрос на комментарии ( 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 в World Wide Web является редактор RFC . Практически любой опубликованный 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. ^ Лесли Daigle (март 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 «обновляет» или «обновляет».