Resumo

  • RFC 1280 era um retrato de coordenação, não um inventário em tempo real: orientava o leitor a buscar a edição atual e proibia o uso daquela cópia após 31 de julho de 1992.
  • STATE indicava a maturidade da especificação; STATUS, o nível de exigência de implementação. Nenhum dos dois comprovava implantação ou funcionamento.

Uma lista pode se tornar enganosa justamente por ser útil. Quem precisava saber em que ponto da padronização um protocolo se encontrava precisava de uma referência comum, não de uma pilha de RFCs separadas. A RFC 1280 tentou oferecer isso ao reunir protocolos, explicar as etapas de padronização e atribuir níveis de exigência. Mas também delimitou a própria autoridade: a edição de março de 1992 deveria sair aproximadamente a cada trimestre e não deveria ser usada depois de julho.

O prazo não significava que todos os protocolos mudariam em 1º de agosto. Ele delimitava o período coberto pelo registro. A IAB orientava os leitores a obter a cópia atualizada no Network Information Center ou na IANA e a consultar as notas sobre mudanças recentes. Em setembro, a RFC 1360 substituiu a RFC 1280. Uma lista oficial podia registrar corretamente uma decisão em sua data e já estar desatualizada quando outra decisão fosse tomada.

A lista separava dois eixos. STATE descrevia a maturidade: padrão, rascunho de padrão, proposta, experimental, informativo ou histórico. STATUS indicava a exigência para implementar: obrigatório, recomendado, eletivo, uso limitado ou não recomendado. Um protocolo proposto podia ser eletivo; uma especificação informativa podia ser recomendada. Um eixo situava a especificação no processo; o outro expressava a expectativa para determinadas classes de sistemas.

Esses eixos não eram um censo de máquinas. A RFC 1280 reconhecia que alguns protocolos de fornecedores haviam se disseminado sem recomendação da IESG ou ratificação da IAB. Já a categoria “experimental” permitia registrar pesquisa sem recomendar uso operacional. A publicação de uma especificação não provava implantação, assim como um marco de padronização não media popularidade. Implementações independentes, interoperabilidade e experiência operacional precisavam de evidências próprias.

Os documentos de referência também não eram atualizados juntos. Assigned Numbers, Gateway Requirements e Host Requirements tinham cronogramas distintos; em caso de divergência, prevalecia o documento mais recente. A RFC 1280 organizava as referências e ajudava a localizar a RFC corrente para cada protocolo, mas não sincronizava todas as especificações. A RFC 1310 descrevia o processo e atribuía à lista periódica o papel de registro autorizado. Essa autoridade continuava limitada por data e escopo: uma entrada histórica não prova o que um protocolo faz hoje, o que foi instalado ou se um serviço respondeu.

Fontes: RFC 1280; RFC 1310; RFC 1360.