Quali RFC dovrebbero essere citati come standard Internet?

È estremamente comune che gli RFC vengano citati a supporto delle opinioni (compresi i Q&A Serverfault), ma il dipendente IT medio ha una comprensione molto scarsa riguardo a quali RFC definiscono gli standard e quali sono puramente informativi. Ciò non dovrebbe sorprendere: gli amministratori di sistema di tutti i livelli di esperienza generalmente evitano di guardare i RFC a meno che non abbiano altra scelta che farlo.

In un sito come il nostro, è estremamente importante non perpetuare equivoci comuni nelle nostre risposte votate. Gli utenti casuali che arrivano dai motori di ricerca supporranno che i voti positivi senza commenti controversi siano sufficienti indicatori del controllo. Di recente mi sono imbattuto in una risposta del 2011, dimostrando che in alcuni casi questo non viene sicuramente catturato mentre votiamo e probabilmente garantisce alcuni sforzi per informare la nostra comunità e Internet in generale.

Quindi, senza ulteriori indugi, come si fa a distinguere tra un RFC quotabile come standard Internet e uno puramente informativo?

Solo gli RFC sulla traccia standard possono essere citati come definizione di uno standard. Per il lettore di passaggio, questi sono i punti principali da capire:

• Alcuni dei vecchi RFC non sono chiaramente etichettati. In caso di dubbi, collegalo alla casella di ricerca all'indirizzo http://www.rfc-editor.org/ e presta attenzione alla colonna Stato . Sii molto cauto con qualsiasi cosa etichettata come Sconosciuta , poiché sono effettivamente abbandonati e non considerati rilevanti.
• Qualsiasi RFC con una designazione di Historic è stato obsoleto, indipendentemente da come è stato originariamente classificato.
• Qualsiasi RFC con uno stato di Standard proposto o Standard Internet può essere utilizzato come riferimento tecnico per lo standard Internet applicabile. Questo è in qualche modo contro-intuitivo e verrà toccato di seguito.

• In tutti gli altri casi, la RFC non può essere considerata una fonte di informazione vincolante e autorevole relativa agli standard Internet.

  • Detto questo, le RFC con una designazione di Best Current Practice (BCP) dovrebbero essere considerate portatrici di un significativo peso consultivo. Non sono vincolanti come lo standard, ma sono fortemente controllati e sottoposti allo stesso controllo che ricevono gli RFC nella traccia degli standard. Ignorarli non viola uno standard, ma di solito è una cattiva idea .
  • Le RFC informative prive dell'identificatore BCP sono meglio paragonate a un articolo che si incontra in una rivista IT. Non tireresti fuori dalla scrivania un pezzo editoriale e diresti a un regista che definisce uno standard, giusto?
  • Le RFC sperimentali possono essere utilizzate solo come riferimento per le funzionalità sperimentali che descrivono e non come riferimento per lo standard a cui sono associate. Esistono nel vuoto fino a quando non vengono promossi alla traccia standard.
  • Occasionalmente un riferimento tecnico può essere pubblicato come RFC informativo prima di essere incorporato come standard Internet. DMARC ( RFC 7489 ) è uno degli esempi moderni più conosciuti di questo. A tutti gli effetti, trattali come faresti con un RFC sperimentale. Esistono nel vuoto e descrivono una funzione opzionale.
• Anche dopo aver esplorato questo labirinto, tieni presente che i nuovi RFC potrebbero aver obsoleto parti significative dell'RFC da cui stai citando! Si consiglia vivamente di utilizzare strumenti che forniscono collegamenti ipertestuali a RFC che aggiornano quello che si sta visualizzando, come quelli forniti da http://tools.ietf.org/ e http://www.rfc-editor.org/ .

Questi sono i punti elenco. Ora entreremo nei dettagli.

RFC 1796 è un buon primer per la maggior parte delle persone che non vogliono passare una giornata a guardare le RFC. Spiega in modo chiaro e conciso l'idea sbagliata comune delle persone supponendo che una RFC definisca sempre uno standard Internet di qualche tipo. Prestare particolare attenzione alla parte in cui i fornitori sono occasionalmente colpevoli di abusare di questa ignoranza quando spingono i loro prodotti.

BCP 9 definisce la traccia degli standard Internet, in particolare la progressione dallo Standard proposto allo Standard Internet . Va notato che questa è una concatenazione di diversi RFC , a partire da RFC 2026 .

Leggere RFC 2026 da solo nel vuoto è un evento comune ma anche una terribile idea:

• RFC 6410 elimina del tutto il concetto di standard di sformo .
• RFC 7127 è un aggiornamento più recente (2014) di BCP 9 che chiarisce che molti standard proposti non vengono mai promossi a standard Internet nonostante l'implementazione diffusa e l'elevata stabilità. Ciò è in gran parte dovuto ai più elevati standard di valutazione a cui sono sottoposti i moderni standard proposti prima di essere classificati come tali. Questa RFC ritrae efficacemente la precedente dichiarazione di RFC 2026 secondo cui "gli attuatori dovrebbero considerare gli standard proposti come specifiche immature" . Non citare mai quella linea a nessuno.

In breve, se un documento RFC è sulla traccia degli standard Internet, ha una maturità sufficiente per essere usato come riferimento tecnico fino a quando un futuro RFC lo aggiorna.

Clausola di esclusione della responsabilità

Come dimostrato sopra, la traccia degli standard Internet definita da BCP 9 è un obiettivo mobile. Questa risposta è un'istantanea nel tempo e potrebbe richiedere un aggiornamento in futuro. Dato il suo stato wiki della community, sentiti libero di farlo o migliorarlo in qualsiasi modo.

La risposta precedente delinea piuttosto bene le categorie di documenti IETF. Tutti gli standard tracciano gli RFC sono elencati qui:

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

Il processo di avanzamento di una RFC da proposta o bozza a standard completo è abbastanza noioso che pochi autori si preoccupano di farlo. Ciò significa che, in pratica, anche se un documento rivisto come RFC 5322 è solo una bozza di standard e il suo predecessore 822 è ancora lo standard Internet nominale, 5322 è quello che la gente segue.