O termo Request for Comments (RFC) remonta ao final dos anos 1960, quando os pesquisadores do projeto ARPANET digitavam suas notas técnicas a cerca de determinado recurso relacionado ao desenvolvimento de mecanismos da rede ARPANET e submetia os seus argumentos aos demais pesquisadores e desenvolvedores a fim de colher sugestões, comentários e eventuais melhoramentos àquilo que estava propondo como melhores práticas e ou padronização.
Com o passar do tempo o projeto ARPANET amadureceu e aquela rede inicial de pesquisa evoluiu bastante e cresceu rapidamente. A partir daí, ela foi renomeada para INTERNET e houve a necessidade de se criar um organismo que pudesse normatizar as suas tecnologias e tudo que pudesse funcionar sobre a pilha TCP/IP. E foi assim que o então grupo do projeto ARPANET deu origem ao IETF (Internet Engineering Task Force). A conformação atual é de grupos de trabalho composto por membros de várias empresas de tecnologia, universidades e instituições de pesquisas que comungam interesses comuns em padronizar determinada funcionalidade, aqui entendido como um protocolo ou aplicação, que possa ser executada sobre a arquitetura TCP/IP.
Hoje um documento rotulado como RFC que estagia no standards track (trilhando as etapas de padronização) especifica, define e descrever um padrão que todos os fabricantes/fornecedores precisam seguir.
Um Internet Standard é um Request for Comments (RFC) especial ou conjunto de RFC’s. Uma RFC que deve se tornar um Padrão ou parte de um Padrão começa como um Internet-Draft, e é depois (geralmente após várias revisões) aceito e publicado pelo Editor RFC como uma RFC e é rotulada como Proposed Standard. Depois, uma RFC é rotulada como Draft Standard e, finalmente, como Standard. Coletivamente, esses estágios são conhecidos como standards track, e estão definidos na RFC 2026. O rótulo Historic é aplicado aos documentos que foram descontinuados no standards-track ou àquelas RFC's obsoletas que foram publicadas antes de o estabelecimento do standards-track.
O termo standards-track é sinônimo de: trilhas de padronização; em fase de padronização; em vias de padronização. A seqüência que uma RFC segue no standards track (tramitando na trilha de padronização) é:
1 – Proposed Standard (padrão proposto);
2 – Draft Standard (anteprojeto do padrão);
3 – Standard (padrão definitivo).
2 – Draft Standard (anteprojeto do padrão);
3 – Standard (padrão definitivo).
Processo de Padronização
Um processo completo para produzir um padrão consiste de quatro etapas no IETF, as quais são chamadas:
1 – Internet Draft (documento rascunho),
2 – Proposed Standard (padrão proposto),
3 – Draft Standard (anteprojeto do padrão), e finalmente
4 – Standard (padrão definitivo).
1 – Internet Draft (documento rascunho),
2 – Proposed Standard (padrão proposto),
3 – Draft Standard (anteprojeto do padrão), e finalmente
4 – Standard (padrão definitivo).
Se uma RFC for parte de uma proposta que está no standards-track, então no primeiro estágio, o padrão é proposto e, subseqüentemente, organizações decidem se implementam esse Proposed Standard. Após três implementações distintas, revisões e correções adicionais serem feitas na RFC, então um Draft Standard é criado. No estágio final, a RFC torna-se um Standard.
Internet-Draft
Essa é fase preliminar durante o desenvolvimento de uma especificação. Especialistas em tecnologia da Internet podem apresentar um Documento-Rascunho em versões preliminares que são disponibilizadas para revisão informal e para receber comentários e sugestões. Esses documentos são colocados no diretório "Internet-Drafts" do IETF, a fim de tornar disponíveis imediatamente tais documentos em evolução ao grande público, facilitando assim o processo de análise e revisão.
Essa é fase preliminar durante o desenvolvimento de uma especificação. Especialistas em tecnologia da Internet podem apresentar um Documento-Rascunho em versões preliminares que são disponibilizadas para revisão informal e para receber comentários e sugestões. Esses documentos são colocados no diretório "Internet-Drafts" do IETF, a fim de tornar disponíveis imediatamente tais documentos em evolução ao grande público, facilitando assim o processo de análise e revisão.
Segundo o IETF, em hipótese nenhuma um Internet-Draft deve ser referenciado por artigos, relatórios ou pedidos-de-proposta, e nenhum fabricante deve argumentar que esteja em conformidade com um Internet-Draft.
Proposed Standard
Um Proposed Standard (PS) é geralmente estável, resolveu escolhas de design conhecidas, acredita-se esteja bem compreendido, recebeu revisão significativa da comunidade, e parece desfrutar de interesse suficiente da comunidade para ser considerado apreciável. Contudo, uma maior experiência pode resultar em alguma mudança ou até mesmo retração da especificação antes de ela avançar. Normalmente, nem implementação e nem experiência operacional é exigido.
Um Proposed Standard (PS) é geralmente estável, resolveu escolhas de design conhecidas, acredita-se esteja bem compreendido, recebeu revisão significativa da comunidade, e parece desfrutar de interesse suficiente da comunidade para ser considerado apreciável. Contudo, uma maior experiência pode resultar em alguma mudança ou até mesmo retração da especificação antes de ela avançar. Normalmente, nem implementação e nem experiência operacional é exigido.
Draft Standard
Uma especificação à qual, ao menos, duas implementações independentes e interoperáveis a partir de bases de código diferentes foram desenvolvidos, e que a experiência operacional bem sucedida suficiente foi atingido, pode ser elevado ao nível Draft Standard (DS).
Um Draft Standard deve ser normalmente considerado como uma especificação final, e mudanças devem ser provavelmente feitas só para resolver problemas específicos encontrados. Em muitas circunstâncias, é razoável aos fabricantes fazerem implementações de Draft Standards em um ambiente sensível a ruptura.
Uma especificação à qual, ao menos, duas implementações independentes e interoperáveis a partir de bases de código diferentes foram desenvolvidos, e que a experiência operacional bem sucedida suficiente foi atingido, pode ser elevado ao nível Draft Standard (DS).
Um Draft Standard deve ser normalmente considerado como uma especificação final, e mudanças devem ser provavelmente feitas só para resolver problemas específicos encontrados. Em muitas circunstâncias, é razoável aos fabricantes fazerem implementações de Draft Standards em um ambiente sensível a ruptura.
Standard
Uma especificação à qual a implementação significativa e experiência operacional bem sucedida foi obtida, pode ser elevada ao nível Internet Standard (STD). Um padrão Internet, que pode ser referido simplesmente como Standard, é caracterizada por alto grau de maturidade técnica e por uma crença generalizada de que o protocolo especificado ou o serviço fornece benefício significativo à comunidade Internet. Geralmente Internet Standards cobrem as questões de interoperabilidade de sistemas na Internet através da definição de protocolos, formatos de mensagens, esquemas e línguas. O mais fundamental dos Standards são aqueles que definem o Internet Protocol (IP).
Todos os Internet Standards recebem um número na série STD – o primeiro documento dessa série, o STD 1, descreve os documentos restantes na série, e tem uma lista dos Proposed Standards.
Cada RFC é estática, ou seja, não mais será alterada; se o documento for alterado, ele é submetido novamente e atribuído um novo número RFC. Se uma RFC se torna um Internet Standard (STD), é-lhe atribuído um número STD, mas mantém seu número RFC. Quando um Internet Standard é atualizado, seu número permanece o mesmo e ele simplesmente se refere a uma RFC diferente ou conjunto de RFC's. Um dado Internet Standard, STD n, pode ser as RFC's x e y em um dado momento, mas depois o mesmo Standard pode ser atualizado para ser RFC z no lugar. Por exemplo, em 2007, a RFC 3700 era um Internet Standard – STD 1 – e em maio de 2008, foi substituída pela RFC 5000, assim a RFC 3700 mudou seu status para Historic, e agora um STD 1 é a RFC 5000. Quando um STD é atualizado novamente, ele é simplesmente referido pela nova RFC, mas ainda será um STD 1. Note que nem todas as RFC's são documentos no standards-track, mas todos os Internet Standards e outros documentos no standards-track são RFC's.
Uma especificação à qual a implementação significativa e experiência operacional bem sucedida foi obtida, pode ser elevada ao nível Internet Standard (STD). Um padrão Internet, que pode ser referido simplesmente como Standard, é caracterizada por alto grau de maturidade técnica e por uma crença generalizada de que o protocolo especificado ou o serviço fornece benefício significativo à comunidade Internet. Geralmente Internet Standards cobrem as questões de interoperabilidade de sistemas na Internet através da definição de protocolos, formatos de mensagens, esquemas e línguas. O mais fundamental dos Standards são aqueles que definem o Internet Protocol (IP).
Todos os Internet Standards recebem um número na série STD – o primeiro documento dessa série, o STD 1, descreve os documentos restantes na série, e tem uma lista dos Proposed Standards.
Cada RFC é estática, ou seja, não mais será alterada; se o documento for alterado, ele é submetido novamente e atribuído um novo número RFC. Se uma RFC se torna um Internet Standard (STD), é-lhe atribuído um número STD, mas mantém seu número RFC. Quando um Internet Standard é atualizado, seu número permanece o mesmo e ele simplesmente se refere a uma RFC diferente ou conjunto de RFC's. Um dado Internet Standard, STD n, pode ser as RFC's x e y em um dado momento, mas depois o mesmo Standard pode ser atualizado para ser RFC z no lugar. Por exemplo, em 2007, a RFC 3700 era um Internet Standard – STD 1 – e em maio de 2008, foi substituída pela RFC 5000, assim a RFC 3700 mudou seu status para Historic, e agora um STD 1 é a RFC 5000. Quando um STD é atualizado novamente, ele é simplesmente referido pela nova RFC, mas ainda será um STD 1. Note que nem todas as RFC's são documentos no standards-track, mas todos os Internet Standards e outros documentos no standards-track são RFC's.
