✖


Jump to content

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

(Перенаправлено с запроса на комментарий )
Информацию о процессе работы с Википедией см. в разделе Wikipedia:Запросы на комментарии .

Запрос на комментарии ( 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]

Функция редактора RFC

[ редактировать ]

С 1969 по 1998 год Джон Постел RFC занимал должность редактора . После его смерти в 1998 году его некролог был опубликован под названием РФК 2468 .

После истечения срока действия первоначального контракта ARPANET с федеральным правительством США Интернет-сообщество, действуя от имени IETF, заключило контракт с Сетевым отделом Университета Южной Калифорнии (USC) Института информационных наук (ISI) о том, чтобы взять на себя функции редактора и издательские обязанности под руководством 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 и функцией редактора 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 and 8174), augmented Backus–Naur form (ABNF) (RFC 5234 ) в качестве мета-языка и простого текстового форматирования, чтобы обеспечить единообразие и простоту понимания RFC. [21]

Подсерия

[ редактировать ]

Серия RFC содержит три подсерии документов IETF RFC: BCP, FYI и STD. Best Current Practice (BCP) — это подсерия обязательных RFC IETF, не входящих в список стандартов. Для вашей информации (к вашему сведению) — это серия информационных RFC, продвигаемых IETF, как указано в RFC 1150 (FYI 1). In 2011, RFC 6360 obsoleted FYI 1 and concluded this sub-series. Standard (STD) used to be the third and highest maturity level of the IETF standards track specified in RFC 2026 (BCP 9). In 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

[ редактировать ] 
RFC 2046 Media Types November 1996


 A. Collected Grammar .................................... 43

1. Introduction

 The first document in this set, RFC 2045, defines a number of header
 fields, including Content-Type. The Content-Type field is used to
 specify the nature of the data in the body of a MIME entity, by
 giving media type and subtype identifiers, and by providing auxiliary
 information that may be required for certain media types. After the
RFC   2046 , определяющий тип MIME text/plain , сам по себе является простым текстом.

Официальным источником RFC во Всемирной паутине является RFC Datatracker. Практически любой опубликованный RFC можно получить по URL-адресу вида https://datatracker.ietf.org/doc/html/rfc5000, показанному для РФК 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 was an Internet Standard—STD 1—and in May 2008 it was replaced with RFC 5000, so RFC 3700 changed to Historic, RFC 5000 became an Internet Standard, and as of May 2008 STD 1 is RFC 5000. as of December 2013 RFC 5000 is replaced by RFC 7100, updating 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 также включает технические рекомендации по применению стандартов Интернета; например, рекомендация использовать фильтрацию источников, чтобы затруднить -атаки ( DoS RFC 2827 : « Фильтрация сетевого входа: борьба с атаками типа «отказ в обслуживании», использующими подмену исходного IP-адреса ») — это BCP 38 .

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

[ редактировать ]

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

Неизвестный

[ редактировать ]

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

[ редактировать ]

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

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

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Перейти обратно: а б с д Сент-Андре, Питер (июнь 2022 г.). Модель редактора RFC (версия 3) . IETF . дои : 10.17487/RFC9280 . РФК 9280 . Серия запросов на комментарии (RFC) — это архивная серия, посвященная документированию технических спецификаций Интернета, ...
  2. ^ «РФЦ» . 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. ^ Перейти обратно: а б «Стивен Д. Крокер, Как в Интернете появились свои правила , 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 г.). РФК   1 . дои : 10.17487/RFC0001 . РФК 1 .
  11. ^ Элизабет Дж. Фейнлер (июль – сентябрь 2010 г.). «Сетевой информационный центр и его архивы» . Анналы истории вычислительной техники . 32 (3): 83–89. дои : 10.1109/MAHC.2010.54 . S2CID   206443021 .
  12. ^ Лесли Дэйгл (март 2010 г.). «Редактор RFC в переходный период: прошлое, настоящее и будущее» . Журнал Интернет-протокола . Том. 13, нет. 1. Сиско Системс. Архивировано из оригинала 20 сентября 2010 года . Проверено 17 августа 2011 г.
  13. ^ Дэйгл, Лесли (июль 2007 г.). Серия RFC и редактор RFC . IETF . дои : 10.17487/RFC4844 . RFC 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. ^ Перейти обратно: а б « Индекс RFC » . Редактор RFC. 25 мая 2008 года . Проверено 26 мая 2008 г.
  22. ^ Руководства и процедуры рабочих групп IETF . дои : 10.17487/RFC2418 . РФК 2418 .
  23. ^ Эта статья основана на материалах, взятых из запроса+комментариев в Бесплатном онлайн-словаре вычислительной техники до 1 ноября 2008 г. и включенных в соответствии с условиями «повторного лицензирования» GFDL версии 1.3 или более поздней.
  24. ^ «Независимые представления» . Редактор RFC . Проверено 5 января 2018 г.
  25. ^ Кленсин, Джон; Талер, Дэвид (июль 2007 г.). Независимая подача в редактор RFC . ИАБ . дои : 10.17487/RFC4846 . RFC 4846 . >
  26. ^ Альвестранд, Харальд; Хаусли, Расс (декабрь 2009 г.). Процедуры IESG для обработки независимых материалов и потоков IRTF . IETF . дои : 10.17487/RFC5742 . РФК 5742 .
  27. ^ «Все ли RFC являются документами стандартов Интернета?» . Редактор RFC . Проверено 16 марта 2018 г.
  28. ^ Уитема, Кристиан ; Постел, Джон ; Крокер, Стив (апрель 1995 г.). Не все RFC являются стандартами . IETF . дои : 10.17487/RFC1796 . РФК 1796 . ... каждый RFC имеет статус…: Информационный, Экспериментальный или Стандартный (Предлагаемый стандарт, Проект стандарта, Интернет-стандарт) или Исторический.
  29. ^ Ноттингем, Марк (31 июля 2018 г.). «Как читать RFC» . Проверено 18 сентября 2023 г. RFC — это архивная серия документов; они не могут измениться[.]
  30. ^ Хаусли, Рассел; Крокер, Дэйв; Бургер, Эрик (октябрь 2011 г.). Сокращение системы стандартов до двух уровней зрелости . IETF . дои : 10.17487/RFC6410 . РФК 6410 .
  31. ^ Упразднение сводного документа «Стандарты официальных протоколов Интернета» . дои : 10.17487/RFC7100 . РФК 7100 .
  32. ^ «7.5. Информационные и экспериментальные RFC» , Дао IETF , получено 26 ноября 2017 г.
  33. ^ Брэднер, Скотт О. (октябрь 1996 г.). Процесс стандартизации Интернета – Редакция 3 . IETF . ППГ 9 . Проверено 25 октября 2017 г.
  34. ^ «Заявление IESG о признании RFC историческими» . IETF. 20 июля 2014 года . Проверено 14 апреля 2016 г.
  35. ^ Стандарты IETF Написано участниками ISC , Консорциумом интернет-систем , 10 сентября 2021 г., заархивировано из оригинала 5 апреля 2022 г. , получено 11 апреля 2022 г. Многие из ранних документов RFC имеют статус «неизвестно», поскольку они пришли из давних времен. Прошла эпоха, когда RFC на самом деле был просто запросом комментариев.
  36. ^ «Воспроизведение RFC» . Траст IETF . Проверено 12 августа 2021 г.
  37. ^ Брэднер, Скотт; Контрерас, Хорхе (ноябрь 2008 г.). Права участников, предоставляемых IETF Trust . IETF . дои : 10.17487/RFC5378 . РФК 5378 .
  38. ^ «Воспроизведение RFC» . Траст IETF . Проверено 13 августа 2021 г.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Request_for_Comments&oldid=1237993881"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 583e6e670c70653c460cf1d4745b3311__1722513540
URL1:https://arc.ask3.ru/arc/aa/58/11/583e6e670c70653c460cf1d4745b3311.html
Заголовок, (Title) документа по адресу, URL1:
Request for Comments - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)