Resumo

  • A RFC 2007 congelou as fichas recebidas até outubro de 1996 e encaminhou atualizações para a versão on-line, um formulário Web, e-mail e uma pequena comissão internacional de voluntários.
  • Categoria, público, idioma, custo, acesso e três datas separavam alegações verificáveis, mas não demonstravam disponibilidade futura, sincronização linguística, qualidade contínua nem resultado de treinamento.

Uma mudança no catálogo não era uma mudança no curso. A RFC 2007 tornou essa diferença visível ao manter Latest-Revision-Date, Record-Last-Modified-Date e Record-Last-Verified-Date. A primeira pertencia ao conteúdo; a segunda, à ficha pública; a terceira, a uma verificação registrada.

Esses relógios podiam divergir. Um mantenedor corrigia o e-mail do autor sem atualizar as aulas. Um produtor revisava o material antes que o catálogo conhecesse a nova versão. Um verificador testava um acesso que poderia falhar depois. Tratar a data mais recente como frescor de tudo apagaria exatamente a informação que o modelo preservava.

Jill Foster, Margaret Isaacs e Mark Prior publicaram a RFC 2007 em outubro de 1996, no fluxo IETF, como documento Informational e FYI 29. O grupo TRAINMAT reagia à expansão do público da Internet. Bibliotecários, equipes de computação e suporte especializado precisavam ensinar uso de serviços, busca e recuperação de informação, e não conseguiam produzir material novo na mesma velocidade.

O catálogo pretendia compartilhar o trabalho existente. Incluía guias de usuário, de recursos e de instrutores, apresentações, exercícios de oficina, material autodidata e coleções on-line. A interpretação de “treinamento” era ampla, mas uma simples lista de comandos não bastava. Conteúdo local só entrava quando oferecia generalidade suficiente para um catálogo internacional.

A seleção buscava qualidade, não totalidade. Materiais com dois anos ou mais exigiam escrutínio cuidadoso; cada item precisava de um mecanismo estabelecido de obtenção, embora pudesse ser pago. Isso configurava uma decisão editorial. Não configurava uma medição padronizada do aprendizado.

O RFC preservava o corte; a rede recebia correções

O texto chama o projeto de “living document” e imediatamente distribui as funções. A versão on-line seria mais atual que o RFC e deveria servir de base para atualizações. A seção de materiais, por sua vez, guardava as fichas recebidas até a data de publicação e avisava que o ambiente on-line poderia ter dados mais novos.

A publicação estática respondia o que o catálogo continha no corte de 1996. O registro mutável tentava responder o que os mantenedores sabiam depois. Se o ambiente on-line apagasse versões anteriores, a auditoria histórica desapareceria. Se o RFC fosse tratado como inventário corrente, coordenadas antigas ganhariam uma validade não prometida.

O formulário HTML era a via preferida para novas fichas e atualizações; o envio por e-mail era a alternativa. Quem criava uma ficha passava a ser registrado como responsável. Um pequeno conselho editorial internacional de voluntários TRAINMAT examinava itens novos e revistos. A atualização era explicitamente de melhor esforço e sujeita a revisão.

Esse arranjo indicava um caminho de responsabilidade, não um prazo de serviço. Produtor, remetente, editor e mantenedor controlavam partes diferentes. O comitê podia aceitar uma descrição; não controlava automaticamente o servidor, o preço, o formato ou a aprendizagem.

O modelo registrava mais que um URL

Identificador, categoria, país, título, autor, organização, nível do público, idioma, palavras-chave, descrição e contato caracterizavam o item. Custo e tipo de acesso indicavam como obtê-lo. E-mail, FTP, Gopher, WWW e mídia fora da rede tinham campos próprios para endereço, comando, URL, login, tamanho, tipo de conteúdo, requisitos, editora e referência.

Notas, data de verificação, data de alteração da ficha e identidade do último modificador pertenciam à custódia do catálogo. O formulário gerava o identificador e a data da alteração automaticamente. A estrutura permitia perguntar se conteúdo, caminho de acesso e registro haviam evoluído juntos.

Os exemplos mostram que não. Algumas fichas listam muitos idiomas com uma única data de revisão; isso registra uma alegação de oferta multilíngue, não prova equivalência entre edições. Há datas de revisão vazias e custos desconhecidos. Pelo menos duas fichas registram Never como última verificação e ainda aparecem no RFC. Inclusão e verificação eram, portanto, estados diferentes.

O método ausente limita a data

A definição diz quando o conteúdo foi verificado pela última vez, mas não explica como. Abrir uma página, baixar um arquivo, testar o programa requerido, ler exercícios e confirmar o preço seriam observações diferentes. O campo também não fornece validade futura nem vigilância contínua.

Para provar disponibilidade atual é necessário observar hoje o canal de acesso. Para provar atualidade é preciso inspecionar o conteúdo. Para comparar idiomas é preciso manter versões e impressões digitais por edição. Para afirmar qualidade ou efeito é preciso conhecer critérios, participantes e resultados. A data e a revisão editorial não contêm esses dados.

A RFC 2007 não deve ser julgada por não prometer tudo isso. Seu cuidado foi deixar as alegações separadas. Receber, incluir, modificar e verificar podiam ocorrer em momentos diferentes. A integridade histórica depende de não promover um desses recibos à autoridade sobre os demais.

Fontes e fronteira

O registro principal é a RFC 2007, com a ficha do RFC Editor e o Datatracker. Os anais da IETF 27 e o arquivo da carta RTC da RIPE registram objetivos anteriores de reunir e classificar materiais. A RFC 2150 mantém a posição no índice FYI; a RFC 1175 delimita a bibliografia geral excluída deste artigo.

As fontes não avaliam um curso atual, uma plataforma moderna ou o efeito de um treinamento específico.