Resumo

  • A RFC 880 registrava em campos separados o status, o texto definidor, os problemas conhecidos, as referências, as dependências e o contato de cada protocolo.
  • Suas linhas impedem uma leitura totalizante: TCP era recomendado com dívidas documentais; TFTP era eletivo e já usado; GGP era experimental e operava nos gateways centrais.
  • Documentos posteriores separaram maturidade e exigência, e o resumo periódico acabou cedendo lugar a uma lista online, que continuou incapaz de provar sozinha a execução.

Em outubro de 1983, a RFC 880, Official Protocols, podia admitir que uma implementação havia se afastado da especificação. Essa frase é mais importante que uma lista limpa de selos. Ela preservava a diferença entre a autoridade do catálogo e a realidade da máquina.

O documento reunia o conjunto oficial de protocolos, mas não o tratava como coleção de produtos concluídos. Cada entrada trazia status, especificação, comentários, referências, dependências e contato. Às vezes também registrava uso observado.

A coleção oficial já estava distribuída

RFC 880 tomou como primeira aproximação o Internet Protocol Transition Workbook de março de 1982. Logo explicou o que escapava dele. Havia protocolos em uso que não estavam no volume, revisões posteriores, novos livros para correio e Telnet, um guia de implementação e opções antigas ainda no manual ARPANET de 1978.

A lista era, portanto, uma reconciliação datada. A RFC 840, antecessora publicada seis meses antes, tinha a mesma arquitetura básica e já era substituída. A atualização mudava a visão documental, não todos os executáveis ao mesmo tempo.

STATUS expressava uma expectativa de adoção. SPECIFICATION apontava o texto. COMMENTS retinha dúvidas e divergências. DEPENDENCIES mostrava os contratos inferiores. CONTACT dava um destino à coordenação. Nenhum campo recebia o direito de inventar o conteúdo dos outros.

As categorias definiam postura, não qualidade absoluta

Required significava que todos os hosts deveriam implementar. Recommended encorajava. Elective permitia escolher. Experimental limitava a implementação aos participantes coordenados da experiência. None dizia que a entrada não era um protocolo.

IP e ICMP eram Required; UDP e TCP, Recommended; TFTP, Elective; EGP e GGP, Experimental. Catenet Model era None por ser descrição de arquitetura.

Essas posições não eram uma nota de segurança. Um item Required ainda precisava ser encontrado no host. Um item Recommended ainda precisava interoperar. Um item Elective podia ser popular. Um item Experimental podia carregar tráfego operacional.

TCP continuava recomendado com problemas à vista

A entrada de TCP apontava a RFC 793 e a marcava como Recommended. Em seguida, dizia que muitas correções haviam sido recebidas, em geral para o documento e não necessariamente para o protocolo.

Event Processing precisava de esclarecimentos. Push ainda parecia uma marca de registro. MSS tinha default e alcance imprecisos. Servidores em escuta, conexões ociosas, dados pendentes durante o fechamento, segmentos fora de ordem e o timeout do usuário também exigiam orientação.

O catálogo não escondia essas dívidas para defender a recomendação. Mantinha a direção coletiva e a incerteza técnica lado a lado. Um inventário que guardasse somente “Recommended” seria menos fiel que a fonte oficial.

O experimental podia estar no centro

EGP era Experimental e estava em desenvolvimento. GGP tinha o mesmo status e era descrito como o protocolo então usado nos gateways centrais. A frase não oferece contagem, conformidade ou disponibilidade. Ela basta para negar que Experimental signifique ausência do ambiente operacional.

O Stream Protocol mostrava o sentido inverso: havia implementação, mas ela podia não corresponder à especificação. Existência não autenticava conformidade.

TFTP era Elective e, ainda assim, usado em várias redes locais. A opção de adotar e a observação de adoção eram informações independentes.

Telnet precisava de uma coluna USE

A tabela de opções Telnet informava o documento RFC ou NIC, presença no novo livreto, presença no manual antigo e USE. Binary Transmission, Echo, Suppress Go Ahead e outras opções atualizadas apareciam como frequentemente implementadas; muitas opções antigas não tinham uso geral.

O conjunto era Elective. Mesmo assim, a lista não inferia que todo sistema Telnet suportava cada função. Um rótulo amplo de compatibilidade não previa qual opção dois pares conseguiriam negociar.

USE não era telemetria completa: faltavam método e denominador. Mas a coluna reconhecia que publicação, permissão e adoção não são a mesma pergunta.

Dependências e contatos limitavam a interpretação

SMTP e Telnet dependiam de TCP; TFTP, de UDP; protocolos de gateway, de IP. Uma linha superior não criava toda a pilha de execução. A cadeia precisava ser verificada em seus próprios termos.

O contato permitia coordenar experiências e encaminhar ambiguidades. Isso não o transformava em soberano de todas as implementações. Apenas recusava a ideia de que uma classificação eliminasse manutenção e responsabilidade.

A RFC 991 continuou a série em 1986, chamando-se relatório oficial de status. As substituições sucessivas tornavam a data parte do registro.

Maturidade e exigência tornaram-se eixos formais

Em 1991, a RFC 1200 separou o STATE de padronização — Standard, Draft Standard, Proposed Standard, Experimental, Informational, Historic — do STATUS de exigência — Required, Recommended, Elective, Limited Use, Not Recommended.

A RFC 2026 detalhou a trilha de padrões e a aplicabilidade. A RFC 6410 reduziu depois a trilha de três níveis de maturidade para dois. O processo podia mudar sem medir uma única instalação.

A publicação periódica também perdeu atualidade. A RFC 7100 aposentou o último resumo e STD 1 em 2013, depois que a lista online do RFC Editor o substituiu. Atualização mais ágil melhora o catálogo; não o converte em observabilidade da rede.

Fontes e limites

O texto usa RFC 840, RFC 880, RFC 991, RFC 1200, RFC 2026, RFC 6410 e RFC 7100. Elas não estabelecem adoção atual, conformidade de produto, segurança presente, política de operador, incidente ou interrupção.