Template RFC

RFC: da ARPANET de 1969 à prática corporativa moderna

RFC significa Request for Comments. O formato foi inventado em abril de 1969 por Steve Crocker para a ARPANET — RFC 1 "Host Software" — e foi usado para definir os protocolos centrais da internet: RFC 791 (IPv4), RFC 793 (TCP), RFC 5246 (TLS 1.2), RFC 9110 (semântica de HTTP, atualização de 2022). Empresas pegaram emprestado o nome e o espírito: uma proposta escrita, distribuída de forma assíncrona, aberta a comentários dos pares, aceita ou recusada por um grupo pequeno de decisores. Cloudflare, Squarespace, Lyft, Etsy, Netflix e Hashicorp mantêm programas internos de RFC.

Uma RFC corporativa costuma conter: problema (o que motiva a mudança), proposta (a mudança em si), design detalhado, alternativas consideradas, drawbacks (seja explícito sobre o que quebra), rationale (por que isto e não as alternativas), questões em aberto e prior art (como outros resolveram o mesmo problema). O fluxo: rascunho → revisão assíncrona → revisão do texto → aceitar ou rejeitar. Muitos times hospedam RFCs em um repositório do GitHub para que a thread de comentários, o histórico e a aceitação vivam num pull request.

Open source como escola de RFCs

O open source ensinou a indústria a rodar processos de RFC públicos. Rust usa o repositório rust-lang/rfcs para toda mudança de linguagem — qualquer pessoa pode abrir um PR de RFC. Python PEP (Python Enhancement Proposal) é o equivalente para Python; historicamente, Guido van Rossum, como BDFL, dava a palavra final. Java JSR (Java Specification Request) roda um processo corporativo mais formal. Ember.js, React Native, Vue e TC39 (comitê que padroniza JavaScript) usam variantes do mesmo padrão.

RFC vs design doc vs ADR

RFC é o estágio de proposta: a mudança está em debate e pode ser recusada. Um design doc descreve um plano já aprovado em detalhe de execução. Um ADR (Architecture Decision Record) é o registro histórico de uma decisão, escrito depois de tomada. Pipeline natural: RFC propõe; uma vez aceita, o time escreve um design doc para construir; as escolhas-chave viram ADRs para leitores futuros.

RFCs famosos (e uma piada famosa)

Um passeio curto: RFC 822 definiu o formato de mensagem de e-mail; RFC 2616 entregou HTTP/1.1; RFC 9110 o substituiu em 2022 com uma especificação mais limpa da semântica de HTTP. A IETF também publica RFCs de primeiro de abril — a mais famosa é a RFC 2324, o Hyper Text Coffee Pot Control Protocol (HTCPCP), motivo pelo qual o status HTTP 418 I'm a teapot aparece em todo framework web. Ferramentas: PRs do GitHub para open source e empresas tech-forward; Google Docs e Notion para o resto.

Perguntas frequentes

RFC vs ADR — qual a diferença? Um ADR registra uma decisão já tomada. Uma RFC propõe uma decisão e convida ao debate. A ordem natural é RFC primeiro, ADR depois.

Quem aprova uma RFC? Depende do time. Engenheiros sêniores mais os stakeholders diretamente afetados. Algumas empresas têm um "grupo de arquitetura" ou "comitê de revisão" explícito; outras conduzem de forma orgânica via revisores de PR.

RFCs devem ser públicas? Projetos open source quase sempre dizem que sim — repositórios públicos de RFC atraem feedback da comunidade. RFCs corporativas internas costumam ser privadas; algumas empresas publicam um subconjunto curado em blogs de engenharia.

Qual o tamanho de uma RFC? O suficiente para tornar a proposta defensável. Curtas cabem em uma página; mudanças substanciais de linguagem ou plataforma facilmente passam de vinte. Tamanho é função do risco, não da formalidade.