Które RFC należy wymienić jako standardy internetowe?

Bardzo często cytowane są RFC na poparcie opinii (w tym pytania i odpowiedzi dotyczące błędów serwera), ale przeciętny pracownik IT bardzo słabo rozumie, które RFC definiują standardy, a które mają charakter wyłącznie informacyjny. Nie powinno to być zaskoczeniem: administratorzy systemów na wszystkich poziomach doświadczenia zwykle unikają patrzenia w RFC, chyba że nie mają innego wyjścia.

Na stronie takiej jak nasza niezwykle ważne jest, abyśmy nie utrwalali typowych nieporozumień w naszych wysoko ocenianych odpowiedziach. Losowi użytkownicy korzystający z wyszukiwarek zakładają, że głosy poparcia bez żadnych spornych komentarzy są wystarczającymi wskaźnikami weryfikacji. Niedawno natknąłem się na odpowiedź z 2011 roku , pokazując, że w niektórych przypadkach zdecydowanie nie zostaje to złapane, ponieważ głosujemy za nią i prawdopodobnie uzasadnia to pewne wysiłki w celu poinformowania naszej społeczności i całego Internetu.

Więc bez zbędnych ceregieli, w jaki sposób rozróżnia się RFC, który jest cytowany jako standard internetowy, i ten, który ma charakter wyłącznie informacyjny?

Tylko RFC na torze standardów mogą być cytowane jako definiujące standard. Dla czytelnika, są to główne punkty do zrozumienia:

• Niektóre starsze RFC nie są wyraźnie oznaczone. W razie wątpliwości podłącz go do pola wyszukiwania na stronie http://www.rfc-editor.org/ i zwróć uwagę na kolumnę Status . Zachowaj ostrożność w przypadku elementów oznaczonych jako Nieznane , ponieważ są one skutecznie porzucane i nie są uważane za istotne.
• Wszelkie RFC z oznaczeniem „ Historic” są przestarzałe, niezależnie od tego, jak zostały pierwotnie sklasyfikowane.
• Każdy dokument RFC o statusie proponowanego standardu lub standardu internetowego może być używany jako odniesienie techniczne do odpowiedniego standardu internetowego. Jest to nieco sprzeczne z intuicją i zostanie omówione poniżej.

• We wszystkich innych przypadkach RFC nie można uznać za wiążące, wiarygodne źródło informacji w stosunku do standardów internetowych.

  • To powiedziawszy, RFC z oznaczeniem Best Current Practice (BCP) należy uznać za mające znaczącą wagę doradczą. Nie są one wiążące w taki sposób, jak norma, ale są silnie sprawdzone i podlegają pewnej kontroli, którą otrzymują RFC na torze norm. Ignorowanie ich nie narusza standardu, ale zwykle jest to zły pomysł .
  • Informacyjne RFC bez identyfikatora BCP najlepiej przyrównać do artykułu, który można znaleźć w czasopiśmie IT. Nie wyciągnąłbyś ze swojego biurka artykułu redakcyjnego i nie powiedziałbyś dyrektorowi, że określa on standard, prawda?
  • Eksperymentalne RFC mogą być używane jedynie jako odniesienie do opisywanych funkcji eksperymentalnych, a nie jako odniesienie do standardu, z którym są powiązane. Istnieją w próżni, dopóki nie awansują do standardowego toru.
  • Czasami odniesienie techniczne może zostać opublikowane jako Informacyjny RFC przed włączeniem go jako standard internetowy. DMARC ( RFC 7489 ) jest jednym z najbardziej znanych współczesnych przykładów tego. We wszystkich zamiarach i celach traktuj je jak eksperymentalne RFC. Istnieją w próżni i opisują opcjonalną funkcję.
• Nawet po przejściu przez ten labirynt pamiętaj, że nowsze wersje RFC mogły nieaktualne znaczące części RFC, które przytaczasz! Zdecydowanie zaleca się korzystanie z narzędzi udostępniających hiperłącza do RFC, które aktualizują przeglądany, takich jak http://tools.ietf.org/ i http://www.rfc-editor.org/ .

To są punktory. Teraz zajmiemy się szczegółami.

RFC 1796 jest dobrym podkładem dla większości ludzi, którzy nie chcą spędzić dnia, wpatrując się w RFC. Wyjaśnia to jasno i zwięźle powszechne błędne przekonanie ludzi zakładających, że RFC zawsze definiuje pewnego rodzaju standard internetowy. Zwróć szczególną uwagę na część, w której sprzedawcy czasami są winni nadużywania tej ignorancji podczas pchania swoich produktów.

BCP 9 określa ścieżkę standardów internetowych, w szczególności przejście od proponowanego standardu do standardu internetowego . Należy zauważyć, że jest to połączenie kilku RFC , począwszy od RFC 2026 .

Samo czytanie RFC 2026 w próżni jest częstym zjawiskiem, ale także strasznym pomysłem:

• RFC 6410 całkowicie eliminuje koncepcję standardów zanurzenia.
• RFC 7127 to nowsza (2014) aktualizacja BCP 9, która wyjaśnia, że ​​wiele proponowanych standardów nigdy nie jest promowanych do standardu internetowego, pomimo powszechnej implementacji i wysokiej stabilności. Jest to w dużej mierze spowodowane wyższymi standardami weryfikacji, które podlegają nowoczesnym proponowanym standardom przed zaklasyfikowaniem jako takie. RFC skutecznie wycofuje wcześniejsze oświadczenie RFC 2026, że „wdrażający powinni traktować proponowane normy jako niedojrzałe specyfikacje” . Nigdy nie podawaj nikomu tej linii.

Krótko mówiąc, jeśli dokument RFC w ogóle znajduje się na torze standardów internetowych, ma wystarczającą dojrzałość, aby można go było wykorzystać jako odniesienie techniczne do momentu, gdy przyszły RFC go zaktualizuje.

Zrzeczenie się

Jak pokazano powyżej, ścieżka standardów internetowych zdefiniowana przez BCP 9 jest ruchomym celem. Ta odpowiedź jest migawką w czasie i może wymagać aktualizacji w przyszłości. Biorąc pod uwagę status wiki społeczności, możesz to zrobić lub ulepszyć w jakikolwiek sposób.

Poprzednia odpowiedź dość dobrze określa kategorie dokumentów IETF. Wszystkie standardy RFC torów są wymienione tutaj:

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

Proces przejścia RFC z proponowanego lub szkicowego do pełnego standardu jest na tyle nużący, że niewielu autorów zadaje sobie z tym trud. Oznacza to, że w praktyce, mimo że zmieniony dokument, taki jak RFC 5322, jest tylko projektem standardu, a jego poprzednik 822 nadal jest nominalnym standardem internetowym, to 5322 jest tym, za którym podążają ludzie.