Quais RFCs devem ser citados como padrões da Internet?

É extremamente comum que os RFCs sejam citados em apoio de opiniões (incluindo perguntas e respostas sobre Serverfault), mas o funcionário médio de TI tem um entendimento muito baixo sobre quais RFCs definem padrões e quais são meramente informativos. Isso não deve surpreender: os administradores de sistema de todos os níveis de experiência geralmente evitam olhar para os RFCs, a menos que não tenham outra opção a não ser.

Em um site como o nosso, é extremamente importante que não perpetuemos mal-entendidos comuns em nossas respostas votadas. Usuários aleatórios que navegam dos mecanismos de pesquisa assumem que votos positivos sem comentários conflitantes são indicadores suficientes da verificação. Recentemente, eu me deparei com uma resposta de 2011, deixando claro que isso definitivamente não está sendo pego em alguns casos, pois aprovamos e provavelmente justificamos alguns esforços para informar nossa comunidade e a Internet em geral.

Portanto, sem mais delongas, como diferenciar uma RFC que é cotável como padrão da Internet e uma que é puramente informativa?

Somente RFCs na faixa de padrões podem ser citados como definindo um padrão. Para o leitor de passagem, estes são os principais pontos a entender:

• Alguns dos RFCs mais antigos não estão claramente identificados. Em caso de dúvida, conecte-o à caixa de pesquisa em http://www.rfc-editor.org/ e preste atenção à coluna Status . Seja muito cauteloso com qualquer coisa rotulada como Desconhecida , pois elas são efetivamente abandonadas e não consideradas relevantes.
• Qualquer RFC com a designação de Histórico foi obsoleta, independentemente de como foi originalmente classificada.
• Qualquer RFC com o status de Proposta de Padrão ou Padrão da Internet pode ser usada como referência técnica para o padrão da Internet aplicável. Isso é contra-intuitivo e será abordado abaixo.

• Em todos os outros casos, a RFC não pode ser considerada uma fonte autorizada e vinculativa de informações relacionadas aos padrões da Internet.

  • Dito isto, os RFCs com a designação de Melhores Práticas Atuais (BCP) devem ser considerados como portadores de peso consultivo significativo. Eles não são vinculativos da maneira que um padrão é, mas são fortemente examinados e passam pelo mesmo escrutínio que os RFCs na faixa de padrões recebem. Ignorá-los não viola um padrão, mas geralmente é uma má ideia .
  • As RFCs informativas sem o identificador BCP são mais bem comparadas a um artigo que você encontra em uma revista de TI. Você não tiraria uma peça editorial da sua mesa e diria a um diretor que ela define um padrão, certo?
  • Os RFCs experimentais podem ser usados ​​apenas como referência para os recursos experimentais que eles descrevem, e não como referência para o padrão ao qual estão associados. Eles existem no vácuo até serem promovidos para a faixa de padrões.
  • Ocasionalmente, uma referência técnica pode ser publicada como uma RFC informativa antes de ser incorporada como um padrão da Internet. O DMARC ( RFC 7489 ) é um dos exemplos modernos mais amplamente conhecidos disso. Para todos os efeitos, trate-os como se fosse uma RFC Experimental. Eles existem no vácuo e descrevem um recurso opcional.
• Mesmo depois de navegar neste labirinto, esteja ciente de que as RFCs mais recentes podem ter obsoleto partes significativas da RFC das quais você está citando! É altamente recomendável usar ferramentas que fornecem hiperlinks para RFCs que atualizam o que você está visualizando, como os fornecidos por http://tools.ietf.org/ e http://www.rfc-editor.org/ .

Esses são os pontos principais. Agora vamos entrar em detalhes.

O RFC 1796 é uma boa cartilha para a maioria das pessoas que não querem passar um dia encarando os RFCs. Isso explica de forma clara e concisa o equívoco comum das pessoas que assumem que uma RFC está sempre definindo algum tipo de padrão da Internet. Preste atenção especial à parte em que os fornecedores ocasionalmente são culpados de abusar dessa ignorância ao empurrar seus produtos.

O BCP 9 define a faixa de padrões da Internet, principalmente a progressão do Padrão Proposto para o Padrão da Internet . Note-se que esta é uma concatenação de várias RFCs , começando com a RFC 2026 .

A leitura da RFC 2026 por si só no vácuo é uma ocorrência comum, mas também uma péssima idéia:

• O RFC 6410 elimina completamente o conceito de Draft Standards .
• A RFC 7127 é uma atualização mais recente (2014) do BCP 9, deixando claro que muitas normas propostas nunca são promovidas para o padrão da Internet, apesar da ampla implementação e alta estabilidade. Isso se deve, em grande parte, aos altos padrões de verificação a que as normas propostas modernas são submetidas antes de serem classificadas como tais. Essa RFC retrai efetivamente a declaração anterior da RFC 2026 de que "os implementadores devem tratar as normas propostas como especificações imaturas" . Nunca cite essa linha para ninguém.

Em resumo, se um documento RFC estiver na faixa dos padrões da Internet, ele tem maturidade suficiente para ser usado como referência técnica até um ponto em que uma futura RFC o atualize.

aviso Legal

Como demonstrado acima, a faixa de padrões da Internet definida pelo BCP 9 é um alvo em movimento. Esta resposta é um instantâneo no tempo e pode exigir atualização no futuro. Dado o status do wiki da comunidade, fique à vontade para fazê-lo ou aprimorá-lo de qualquer forma.

A resposta anterior apresenta as categorias de documentos IETF muito bem. Todos os RFCs de controle de padrões estão listados aqui:

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

O processo de avançar uma RFC da proposta ou do rascunho para o padrão completo é tedioso o suficiente para que poucos autores se preocupem em fazê-lo. Isso significa que, na prática, mesmo que um documento revisado como o RFC 5322 seja apenas um rascunho do padrão e seu predecessor 822 ainda seja o padrão nominal da Internet, 5322 é o que as pessoas seguem.