Todas as páginas deste site citam RFCs

Abra qualquer documentação de ferramenta deste site, ou qualquer artigo sobre protocolo, e você vai achar um número de quatro dígitos depois das letras : a RFC 2616 para o HTTP (Hypertext Transfer Protocol), a RFC 8446 para o TLS (Transport Layer Security) 1.3, a RFC 1918 para as faixas de endereço privado que você atribui toda semana. Quem trabalha na área cita esses números o tempo todo, mas quase ninguém aprende o que é a série, quem decide o que entra nela ou por que um documento que define o protocolo por onde passa a maior parte do comércio mundial tem como título um pedido de comentários.

Abril de 1969: a cautela que virou tradição

Em 1969, a ainda não funcionava. Um punhado de alunos de pós-graduação em quatro universidades escrevia o software que ia fazer quatro computadores conversarem, e os professores, que poderiam ter imposto um projeto, não faziam isso. , então na UCLA, passou a limpo as anotações do grupo sobre software de host e esbarrou num problema de legitimidade: ele era um estudante, sem autoridade para mandar em ninguém. A saída foi o título. Ele chamou o texto de Request for Comments para não parecer presunçoso nem falar com ar de autoridade, e o publicou em 7 de abril de 1969 como a RFC 1. Mais tarde, ele disse que, embora boa parte do desenvolvimento tenha seguido um grande plano, a criação das RFCs foi em grande parte acidental.

A cultura se firmou em poucas semanas, nos próprios documentos. A RFC 3, de abril de 1969, se chama Documentation Conventions e diz, num dos trechos, que o Network Working Group "seems to consist of" cinco pessoas, que ela cita pelo nome, e que "membership is not closed", ou seja, o grupo está aberto a novos participantes. Diz também que "Notes may be produced at any site by anybody and included in this series": qualquer pessoa, em qualquer lugar, pode escrever uma nota e incluí-la na série. O conteúdo pode ser qualquer ideia ou sugestão ligada ao software de host. E vem a frase que vale decorar: "notes are encouraged to be timely rather than polished", isto é, mais vale a nota sair no tempo certo do que sair polida. Posições filosóficas sem exemplos, sugestões específicas sem contexto e perguntas explícitas sem nenhuma tentativa de resposta: a RFC declara, com todas as letras, que tudo isso é aceitável.

Isso é um modelo de governança disfarçado de guia de estilo. Qualquer um pode escrever; nada precisa estar pronto; perguntar já conta como contribuição. Na RFC 53, de junho de 1970, Crocker já descrevia como um protocolo oficial host a host seria definido e alterado (propostas circulando como RFCs, uma data de corte, comentários de qualquer interessado), e isso é, em miniatura, o processo que a Internet Engineering Task Force () segue até hoje. A série começou antes de existir e-mail; as primeiras RFCs eram datilografadas, copiadas e mandadas pelo correio.

O que os números querem dizer de verdade

Quatro pontos confundem até quem cita RFCs todo dia.

Uma RFC não é necessariamente um padrão. A série traz padrões propostos, documentos informativos, protocolos experimentais, boas práticas atuais (Best Current Practice) e piadas assumidas, e o número não diz qual é qual. O status é um metadado, que aparece impresso no documento e no índice. Muitas das RFCs mais citadas no dia a dia da operação (a RFC 1918, sobre endereços privados, é uma delas) são Best Current Practice, e não padrões.

RFCs nunca são revisadas. Uma RFC publicada não muda mais. Quando a especificação muda, sai uma RFC nova que torna a antiga obsoleta, e a antiga continua onde está, marcada como obsoleta. É por isso que o HTTP/1.1 aparece como RFC 2616 na documentação mais antiga e como RFCs 7230 a 7235, e depois RFC 9110 em diante, na mais nova: o protocolo não mudou de nome, os documentos é que foram substituídos. Quem cita um comportamento de uma versão específica deveria conferir se a RFC citada já ficou obsoleta, porque o próprio arquivo da internet entrega, sem reclamar, um documento que deixou de valer em 2014.

Um draft não é uma RFC. O trabalho acontece nos Internet-Drafts, que expiram em seis meses e, de forma explícita, não servem de referência para nada. Um protocolo pode estar amplamente implantado enquanto ainda é draft (foi o caso do QUIC), e quem lê documentação de fabricante deveria reparar qual dos dois está sendo citado.

O número é cronológico, não hierárquico. A RFC 9293 não é mais importante que a RFC 793; é o mesmo protocolo, o TCP (Transmission Control Protocol), especificado de novo cinquenta anos depois.

Sem reis

A IETF nasceu em 1986, da tradição de grupos de trabalho que as RFCs tinham criado. O espírito dela ganhou a forma definitiva com , do MIT, numa apresentação de 1992, num slide que desde então é citado em toda discussão sobre a governança da internet: rejeitamos reis, presidentes e votação; acreditamos em rough consensus e running code, o consenso aproximado e o código que roda.

As duas metades importam, e a segunda é a que o pessoal de operação sente na pele. Rough consensus não é unanimidade nem votação por maioria: é a avaliação de quem coordena o grupo de trabalho de que as objeções foram ouvidas e tratadas, o que faz da padronização uma questão de argumento, e não de contagem de votos. Running code quer dizer que se espera que alguém já tenha implementado a especificação antes de ela receber a bênção, e é por isso que os protocolos da internet costumam ser coisas que já funcionam, e não coisas que deveriam funcionar. A guerra dos protocolos entre o e a pilha OSI, formalmente correta, foi decidida justamente por essa diferença: um lado tinha um comitê e um documento; o outro tinha código rodando e uma base instalada.

Para quem lê uma especificação, a consequência prática é esta: uma RFC descreve o que os implementadores combinaram fazer, e não o que um órgão de padronização decretou. Quando duas implementações divergem, muitas vezes é a RFC que está ambígua, e não uma das implementações que está errada; e as brigas sobre essa ambiguidade estão nos arquivos públicos das listas de discussão, que qualquer um pode ler.

O primeiro de abril

A série publica uma RFC de primeiro de abril em quase todos os anos desde 1978, e vale conhecer essas RFCs porque é com elas que a comunidade defende argumentos técnicos por meio do humor.

A RFC 1149, de 1º de abril de 1990, especifica a transmissão de datagramas IP por avian carriers, ou seja, por pombos-correio: os datagramas são impressos em rolos de papel e amarrados na perna de um pombo. A piada tem um fundo sério: é uma demonstração válida, ainda que absurda, de que o IP não se importa com a camada de enlace que está embaixo dele, e esse é todo o argumento a favor da divisão em camadas. Em 28 de abril de 2001, o Bergen Linux User Group implementou a RFC de verdade: imprimiu cada pacote de ping em hexadecimal, prendeu cada um num pombo com fita adesiva e escaneou o papel do outro lado, a uns cinco quilômetros de distância. O relato do próprio grupo registra o resultado: nove pacotes enviados, quatro respostas e tempos de ida e volta entre 3.211 e 6.389 segundos, com um atraso de cerca de uma hora porque os pombos resolveram voar primeiro com o bando de um vizinho. Depois, a RFC 2549 acrescentou qualidade de serviço, e a RFC 6214 atualizou o protocolo para IPv6.

A , de 2003, propõe a security flag (flag de segurança) no header IPv4: um único bit que os atacantes ligam para declarar que os seus pacotes são maliciosos, de modo que o firewall só precisa testar esse bit. A piada é um argumento sério sobre a diferença entre descrever uma intenção e aplicar uma política, e ela é citada toda vez que um produto diz que detecta intenção a partir de um campo de header. O pessoal da área chama esse bit de evil bit (o bit do mal), e o nome virou o jeito padrão de falar de um controle que depende da cooperação do atacante.

Por que o nome resistiu

O nome atravessou nove mil documentos e cinquenta e sete anos, e ainda diz algo verdadeiro sobre como a internet é especificada: ninguém ali tem autoridade para mandar, então o acordo precisa ser construído em público, por escrito, por pessoas que mostram como chegaram às suas conclusões. O artigo sobre a EFF conta o processo judicial que firmou o entendimento de que código-fonte é uma forma de expressão; esta série é a versão mais antiga e mais discreta da mesma ideia. A especificação da rede é um documento público, que qualquer um pode ler, citar, criticar ou implementar, e é assim desde a primeira RFC, escrita por um estudante que não se via no comando de nada.

Fontes