Introdução

Por várias vezes foi falado neste blogue, que não dá para procurar e ler um RFC, sem a listagem do RFC Index, em ordem numérica, numa tela de navegador. É o que mostra a Figura 1, parcialmente.

O RFC mais importante, para entender RFCs é o RFC2026⁴. A Figura 2 mostra como a referência aparece no RFC Index. Tudo o que é apresentado nas três linhas da Figura 2, está explicado no início da página do RFC Index, e seria muito proveitoso, entender, principalmente o que está em vermelho.

Não marcado na Figura 2, está (TXT = 86731), que diz estar o RFC2026⁴, no formato ASCII, com 86.731 caracteres. Outros formatos possíveis para um RFC são o PostScript (PS) e o PDF. Já marcado, na sequência está Obsoletes indicando que o RFC2026⁴ torna obsoleto ou substitui dois outros RFCs. Mas, uma palavra parecida e muito mais importante é Obsoleted by, que embora não apareça na descrição do RFC2026 poderia, quando for o caso, evitar perda de tempo, sabendo que um determinado RFC foi substituído por outro. Duas importantes informações, que geralmente não são consideradas, Status e Stream são as principais motivações deste texto.

Na medida do possível, não será apresentado neste texto, a interpretação de siglas, como por exemplo, a sigla RFC. Mas se necessário pode-se recorrer à Tabela 1 do artigo A ISOC, o IETF e a infraestrutura da Internet. Uma outra dúvida que aparece é o tratamento dado ao RFC. Está sendo usado “o”, ao invés de “a”. Tanto faz. O artigo masculino está sendo preferido indicando que a tradução para “Request” será “Pedido”. Esta correção de gênero está sendo feita somente a partir do presente artigo, já que nos artigos passados do blogue, foi dado preferência ao gênero feminino. No início irá parecer um pouco estranho, na língua portuguesa.

Nota: Experimentalmente há um espelhamendo do RFC Index, em ordem decrescente pelo número do RFC, aqui. Foi usado a recomendação contida em How to use rsync to download documents from the RFC Editor Repository, e um programa em PHP analisa o arquivo em XML, rfc-index.xml, para obter um formato bem próximo ao do RFC Index, mostrado na Figura 1.

Quem pode escrever um RFC?

Qualquer ser humano pode escrever um RFC, desde que o faça, em inglês e siga a formatação recomendada. Para ser publicada, entretanto, ela deve passar por algumas etapas bem definidas. Tais etapas, a formatação e os tipos de RFCs estão descritas em dezenas de RFCs…

A publicação e o repositório de RFCs são de responsabilidade do RFC Editor, embora não pareça à primeira vista é formado por um conjunto de pessoas (e, de organizações), que atuam sobre um emaranhado complexo de normas, regras e definições, para eficazmente expor, de maneira simples, um imenso conhecimento sobre a Internet, seus protocolos e milhares de outras informações úteis a pessoas e instituições envolvidas e / ou interessadas. No passado, entretanto, o RFC Editor era uma única pessoa: Jon Postel. Foi Postel quem estabeleceu o perfeito funcionamento do RFC Editor, e em FAQs² tem-se um bom lugar para entender muito a respeito. Um cenário simplificado em torno do RFC Editor é mostrado na Figura 3.

O RFC Editor cuida da publicação e o repositório de RFCs. Este pode ou não se tornar um RFC. O repositório dos RFCs está no ambiente do RFC Editor, enquanto que o repositório de Internet-Drafts está no ambiente dos Grupos de Trabalhos. No passado já tivemos outros tipos de documentos, como os chamados FYI (For You Information), que desde o RFC6360¹⁰, não existem mais. As regras de um Internet-Draft estão muito claras em Guidelines to Authors of Internet-Drafts.

Os membros do RFC Editor são determinados pelo IAB e pelo IAOC, que usam, quando necessário, o NomCom. O suporte financeiro e administrativo é dado pelo IASA. Este relacionamento do RFC Editor como o IAB, IAOC e IASA, estão muito bem definidos em RFCs. O IAB exerce funções de supervisão e monitoramento do RFC Editor, também, caracterizadas em RFCs.

Os I-Ds, ao longo do tempo, após uma sequência de encaminhamentos transformam-se em RFCs. O I-Ds são produzidos pelos participantes dos WGs ou individualmente (produção independente). O IESG é a organização envolvida na autorização final para que o RFC Editor publique formalmente um I-D, como um RFC.

O IAB tem privilégios na publicação de documentos, exceto aqueles que envolvam propostas diretamente ligadas ao IETF. Neste caso, o documento é enviado para o IETF, submetido a avaliações e debates tradicionais, para em seguida ser autorizado pelo IESG. O IESG tem sempre a palavra final, pois mesmo um documento informal ou que veio de uma submissão independente pode estar em conflito com alguma norma, regra ou padrão envolvendo a Internet. O RFC Editor é muito cuidadoso e hábil em relação a isto, envolvendo-se sistematicamente com o IESG, o que dá segurança a todo o repositório.

Tipos de documentos e as submissões (“stream“)

O RFC é dividido em outros tipos, denominados sub-séries. Algumas outras formas de identificar os documentos do RFC Editor podem ser usados, como por exemplo em RFCs by Category.

Na Figura 3 são três as sub-séries identificadas pela categoria Standard Track: Proposed Standard, Draft Standard e Internet Standard, este recentemente denominado, simplesmente Standard. São, tipicamente, documentos produzidos pelo IETF, cujo caracterização é definida no RFC202, item 4, e são identificados como níveis de maturidade. Complementarmente, o RFC5000, detalha o tratamento dado pelo RFC Editor, aos documentos dos níveis de maturidade. O RFC2026⁴, também, regula as publicações do tipo Internet-Draft, que na prática podem anteceder os níveis de maturidade e são produzidos dentro dos WGs do IETF. Da mesma forma, a RFC2026, inclui em suas caracterizações, as séries Informational e Experimental, o que faz com que o RFC Editor adote critérios que podem envolver o IAB e o IESG. Neste sentido, estes dois tipos de documentos (Informational e Experimental) podem sofrer um processo de quarentena, adequado período de avaliação e debates. Se os documentos destes dois tipos são produzidos pelos WGs, necessariamente devem ser submetidos ao IESG, por uma razão de motivos, descritos no item 4.2.3, do RFC2026⁴. Mais recentemente, uma atualização do RFC2026⁴, o RFC6410, propõe dois níveis de maturidade, ao invés de três.

A sub-série Historic está caracterizada no item 4.2.4 da RFC2026⁴. Da mesma forma, a sub-série Best Current Practice, descrita no item 5 é considerada um nível de maturidade elevado, representando o ponto de vista de uma comunidade sobre o que é melhor, no que diz respeito ao domínio de sua aplicação. Muitos RFCs aparecem a palavra “unknown“, no “status“, o que significa que foram publicadas antes da definição formal.

As submissões independentes foram atualizadas pelo RFC5742, onde os critérios de revisão a serem adotados pelo IESG estão bem qualificados.

Finalmente é bom lembrar que a palavra submissão é uma tradução livre para stream. Stream está caracterizado na referência de um RFC, como mostrado na Figura 2. No exemplo, da Figura 2, o RFC2026⁴ foi submetido pelo IETF. Quando a submissão vem do IETF, a palavra “Area” é adicionada, para identificar a área do IETF e o respectivo WG, que deu origem ao documento. A Figura 4 exibe as possíveis submissões ou valores do “stream”.

As submissões do IRTF estão reguladas pelo RFC5743, também, complementadas pelo RFC4844⁶.

As submissões independentes estão reguladas pelo RFC4846. A submissão independente deve ser feita diretamente ao RFC Editor, na forma de Internet-Drafts.

Como escrever um RFC ou Internet-Draft

Existem ferramentas que facilitam a criação de documentos, seguindo as normas do RFC Editor. Existe disponível, o completo Tutorial: Tools for Creating I-Ds, e mais um outro, RFCs & the RFC Editor: A Tutorial. Complementarmente, o RFC2360 é um guia para quem pretende escrever um documento sobre padrões, que pode ser complementado pelo RFC2223 e o RFC5741⁸.

Conclusões

É importante lembrar, que o começo para o entendimento completo sobre os documentos do RFC Editor está no RFC2026⁴ e na sua página principal. Entender detalhadamente, as regras que norteiam o trabalho do RFC Editor, apesar de muitíssimo importante é uma tarefa árdua, senão impossível. A Figura 3, juntamente com este texto é apenas uma demonstração da complexidade, mas caracteriza muito bem a isenção e confiabilidade da documentação que faz a Internet funcionar. O melhor que se tem a fazer é, após a identificação do trabalho a ser realizado, partir para efetivamente escrever o documento. Nesta oportunidade, as coisas ficarão mais claras e fáceis de entender, em particular, o percurso que um documento até chegar a um RFC publicado.

Artigos Relacionados

• A ISOC, o IETF e a infraestrutura da Internet

• IETF => D-75: O comitê de nomeação

• IETF => D-58: Como participar dos encontros do IETF

Referências

1. RFC Editor FAQs. Acessado em 02/02/2013.

2. RFC1796 Not All RFCs are Standards C. Huitema, J. Postel, S. Crocker [ April 1995 ] (TXT = 7049) (Status: INFORMATIONAL) (Stream: Legacy). Acessado em 02/02/2013.

3. RFC Editor FAQs. Acessado em 02/02/2013.

4. RFC2026 The Internet Standards Process — Revision 3 S. Bradner [ October 1996 ] (TXT = 86731) (Obsoletes RFC1602, RFC1871) (Updated-By RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC5657, RFC5742, RFC6410) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (Stream: IETF, Area: gen, WG: poised95). Acessado em 02/02/2013.

5. RFC2119 Key words for use in RFCs to Indicate Requirement Levels S. Bradner [ March 1997 ] (TXT = 4723) (Also BCP0014) (Status: BEST CURRENT PRACTICE) (Stream: Legacy). Acessado em 01/02/2013.

6. RFC4844 The RFC Series and RFC Editor L. Daigle, Internet Architecture Board [ July 2007 ] (TXT = 38752) (Updated-By RFC5741) (Status: INFORMATIONAL) (Stream: IAB). Acessado em 01/02/2013.
   

7. RFC4845 Process for Publication of IAB RFCs L. Daigle, Internet Architecture Board [ July 2007 ] (TXT = 9228) (Status: INFORMATIONAL) (Stream: IAB). Acessado em 01/02/2013.

8. RFC5741 RFC Streams, Headers, and Boilerplates L. Daigle, O. Kolkman, IAB [ December 2009 ] (TXT = 32160) (Updates RFC2223, RFC4844) (Status: INFORMATIONAL) (Stream: IAB). Acessado em 02/02/2013.

9. RFC5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions H. Alvestrand, R. Housley [ December 2009 ] (TXT = 21067) (Obsoletes RFC3932) (Updates RFC2026, RFC3710) (Also BCP0092) (Status: BEST CURRENT PRACTICE) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 02/02/2013.

10. RFC6360 Conclusion of FYI RFC Sub-Series R. Housley [ August 2011 ] (TXT = 4729) (Obsoletes RFC1150) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 01/02/2013.