Які RFC слід називати стандартами Інтернету?

Вкрай часто для RFC посилаються на підтримку думок (включаючи Q&A Serverfault), але середній ІТ-працівник дуже погано розуміє, які RFC визначають стандарти, а які - суто інформативні. Це не повинно дивувати: системні адміністратори всіх рівнів досвіду зазвичай уникають скління очей на RFC, якщо у них немає іншого вибору, крім як.

На такому сайті, як наш, вкрай важливо, щоб ми не продовжували поширених непорозумінь у своїх схвалених відповідях. Випадкові користувачі, що курсують з пошукових систем, вважають, що відгуки, що не мають суперечливих коментарів, є достатніми показниками перевірки. Нещодавно я натрапив на відповідь від 2011 року, зробивши очевидним, що це, безумовно, не потрапляє в деяких випадках, оскільки ми заявляємо, що, мабуть, вимагає певних зусиль для інформування нашої громади та Інтернету взагалі.

Отже, без подальшої приналежності, як можна розмежовувати RFC, який є кошторисом як Інтернет-стандарт, і той, який є суто інформативним?

Тільки RFC на треку стандартів можна вважати такими, що визначають стандарт. Для читача мимохідь, це основні моменти, які потрібно зрозуміти:

• Деякі з старих RFC чітко не позначені. Якщо ви сумніваєтесь, підключіть його до вікна пошуку за адресою http://www.rfc-editor.org/ та зверніть увагу на стовпець " Статус ". Будьте дуже обережні з будь-чим, позначеним як Невідоме , оскільки вони фактично відмовились і не вважаються релевантними.
• Будь-який RFC із позначенням Historic застарів, незалежно від того, як він був класифікований.
• Будь-яка RFC зі статусом запропонованого стандарту або Інтернет-стандарту може використовуватися як технічна довідка для відповідного Інтернет-стандарту. Це дещо контрінтуїтивно, і це буде торкатися нижче.

• У всіх інших випадках RFC не може вважатися обов'язковим, авторитетним джерелом інформації стосовно стандартів Інтернету.

  • З огляду на це, ДРК з позначенням найкращої сучасної практики (БКП) слід розглядати як такі, що несуть значну консультативну вагу. Вони не є обов'язковими для того, як стандарт, але вони проходять ретельну перевірку та проходять певний той же контроль, який отримують RFC у стандартній доріжці. Ігнорування їх не порушує стандарт, але зазвичай це погана ідея .
  • Інформаційні RFC, у яких відсутній ідентифікатор BCP, найкраще уподібнюються до статті, яку ви зустрічаєте в IT-журналі. Ви б не виймали редакційну частину зі свого столу і говорили режисеру, що вона визначає стандарт, правда?
  • Експериментальні RFC можуть використовуватися лише як орієнтир для експериментальних особливостей, які вони описують, а не як еталон для стандарту, з яким вони пов'язані. Вони існують у вакуумі до тих пір, поки не будуть просунуті до рівня стандартів.
  • Інколи технічна довідка може бути опублікована як Інформаційна RFC до того, як вона буде включена в Інтернет-стандарт. DMARC ( RFC 7489 ) - один з найбільш широко відомих сучасних прикладів цього. З усіма намірами та цілями ставитесь до них так, як би ви зробили експериментальний RFC. Вони існують у вакуумі та описують необов'язкові функції.
• Навіть коли ви перейдете по цьому лабіринту, пам’ятайте, що нові RFC можуть застаріти значні частини RFC, які ви цитуєте! Настійно рекомендується використовувати засоби, що надають гіперпосилання на RFC, які оновлюють переглянуті, такі, як надані http://tools.ietf.org/ та http://www.rfc-editor.org/ .

Це точки кулі. Тепер ми розберемося з специфікою.

RFC 1796 - хороший ґрунтовник для більшості людей, які не хочуть провести день, дивлячись на RFC. Це чітко і стисло пояснює поширену помилкову думку людей, припускаючи, що RFC завжди визначає певний Інтернет-стандарт. Зверніть особливу увагу на частину, в якій продавці періодично винні у зловживанні цим незнанням під час натискання на свої товари.

BCP 9 визначає напрямок Інтернет-стандартів, особливо перехід від пропонованого стандарту до стандарту Internet . Слід зазначити, що це об'єднання декількох RFC , починаючи з RFC 2026 .

Читання RFC 2026 самотужки у вакуумі є звичайним явищем, але також жахлива думка:

• RFC 6410 повністю виключає концепцію проекту стандартів .
• RFC 7127 - це нещодавнє (2014 р.) Оновлення до BCP 9, що дозволяє зрозуміти, що багато запропонованих стандартів ніколи не просуваються до Інтернету-стандарту, незважаючи на широке впровадження та високу стабільність. Це значною мірою пояснюється вищими стандартами перевірки, яким підлягають сучасні пропоновані стандарти перед класифікацією як такі. Цей RFC ефективно відкликає попереднє твердження RFC 2026 про те, що "Виконавці повинні ставитись до запропонованих стандартів як до незрілих специфікацій" . Ніколи нікому не цитуйте цей рядок.

Коротше кажучи, якщо документ RFC взагалі перебуває в інтернеті стандартів Інтернету, він має достатню зрілість, щоб його можна використовувати як технічну довідку до такого моменту, що майбутня RFC не оновить його.

Відмова від відповідальності

Як показано вище, трек стандартів Інтернету, визначений BCP 9, є рухомою ціллю. Ця відповідь є часом в часі і може потребувати оновлення в майбутньому. Враховуючи статус вікі-спільноти, сміливо робіть це чи вдосконалюйте його.

У попередній відповіді досить добре розміщені категорії документів IETF. Усі стандарти відстежують RFC перераховані тут:

https://www.rfc-editor.org/standards

Процес просування RFC від запропонованого або проектного до повного стандарту є досить стомлюючим, що мало хто з авторів намагається це зробити. Це означає, що на практиці, хоча перероблений документ, як RFC 5322, є лише проектним стандартом, а його попередник 822 все ще є номінальним стандартом Інтернету, 5322 - це той, кого слідкують.