Resumo

  • No RFC 1578, um terminal remoto, uma rede de armazenamento e encaminhamento, um host SLIP/PPP e uma LAN ligada por roteador não ofereciam o mesmo conjunto de aplicações.
  • A filtragem podia dar algum controle à escola, mas não garantia a exclusão absoluta de material inadequado. O correio eletrônico continuava sendo um caminho possível.
  • A política de uso aceitável do provedor regulava a conexão. A escola ainda precisava de política própria, formação, suporte, supervisão e uma decisão comunitária sobre o acesso dos alunos a partir de casa.

A parte que não vinha discriminada na cobrança

O RFC 1578 foi publicado em fevereiro de 1994. Seu registro no RFC Editor o classifica como Informational e FYI 22, não como padrão. O grupo Internet School Networking o preparou para professores, bibliotecários, especialistas de mídia e administradores do ensino básico que acabavam de se conectar, usavam acesso indireto ou avaliavam uma conexão.

O documento reconhecia que essa população geralmente tinha menos experiência com redes de dados e menos recursos de suporte técnico e ao usuário do que outros grupos. A chegada da Internet à escola, portanto, trazia perguntas que o protocolo não respondia: quem usaria, em que lugar, com que formação, quem prestaria ajuda, quais conteúdos seriam oferecidos e quais regras valeriam.

Alguns serviços voltados à educação ofereciam material curricular, coordenação de projetos e atendimento técnico, mas não todos os serviços básicos da Internet. O RFC dizia que, se a pessoa pudesse usar Telnet e FTP além de correio, provavelmente estava “na” Internet. Esse advérbio preservava a dúvida correta: a marca do serviço não era um inventário completo das capacidades.

Havia mais de uma forma de estar conectado

Na opção mais simples, computador, modem e emulador de terminal chamavam um serviço remoto. Com SLIP ou PPP, o computador se tornava efetivamente um host da Internet e podia executar aplicações TCP/IP. Uma ligação mais ampla unia a LAN da escola ou de um departamento ao roteador do provedor por uma linha permanente.

O armazenamento e encaminhamento com UUCP oferecia outro conjunto. Mensagens e artigos de Usenet ficavam guardados até a chamada programada para o próximo computador. Listas e alguns serviços de arquivos funcionavam por correio, mas aplicações interativas eram limitadas. Havia economia de chamadas e a escola podia escolher parte das informações que aceitaria transportar.

Esses arranjos não eram apenas pacotes de preço. Uma sessão de terminal comprovava acesso à máquina remota usada naquela sessão, não uma pilha IP local. Um enlace PPP ampliava as possibilidades de um computador, não demonstrava cobertura de todas as salas, capacidade no horário de pico ou suporte. Um roteador ativo comprovava um caminho para a LAN, não que a aplicação pedagógica funcionava. A entrega posterior de uma mensagem em fila não comprovava interatividade.

Quando o relatório reduz tudo a “escola conectada”, deixa de informar de onde o teste partiu, qual conta foi usada, qual aplicação respondeu, sob qual carga e durante quanto tempo. A linha é um fato; o serviço utilizável é outro.

A infraestrutura humana era um custo operacional

O RFC 1578 chamava a formação de um dos aspectos mais negligenciados do plano tecnológico de uma escola. A falta dela podia levar o plano ao fracasso. Professores, bibliotecários, alunos, administradores e outros trabalhadores precisariam de preparação.

No modelo de formar formadores, um grupo pequeno aprendia primeiro e depois atendia às necessidades específicas dos colegas. O suporte técnico podia ficar no distrito, vir de voluntários de empresas ou órgãos públicos, ser oferecido pelo fornecedor ou acontecer em parte remotamente pela própria rede.

O RFC 1359, cuja ficha oficial o apresenta como orientação para instituições que pretendiam se conectar, havia organizado essa conta em 1992. Custos duros incluíam circuitos, modems e roteadores. Custos menos visíveis incluíam educação da equipe, mudança na estrutura de suporte e implantação de aplicações. Planejamento, partida, produção e avaliação também eram fases distintas.

Assim, era possível ter uma linha paga e nenhum tempo reservado para o professor aprender. Um entusiasta podia manter o projeto sem substituto. Uma rede podia operar sem mesa de ajuda. Essas lacunas não necessariamente apagavam a luz do modem, mas reduziam a capacidade sustentada da instituição.

O filtro não eliminava os caminhos que não governava

O RFC tratava a filtragem como vantagem do armazenamento e encaminhamento: a escola ganhava algum controle sobre as informações disponíveis. Ao mesmo tempo, dizia que, numa conexão direta e muitas vezes até numa indireta, não era possível usar uma solução técnica para impedir todo acesso a material considerado inadequado para crianças.

O correio eletrônico mostrava por quê. Mesmo que o sistema não carregasse determinado repositório ou grupo, alguém de fora poderia enviar o conteúdo por mensagem. Bloquear uma superfície não encerrava todas as outras.

Isso não torna a filtragem inútil. Uma requisição bloqueada comprova que uma regra foi aplicada por um controle específico naquele momento. Não comprova que o correio estava coberto, que outra conta não podia chegar ao mesmo material ou que não havia outro serviço. O RFC limitava a conclusão ao alcance testado.

Por isso o documento acrescentava regras claras, consequências, educação ética e supervisão razoável. A escola também podia limitar horários e oportunidades de uso, embora ensinar responsabilidade como parte normal do currículo fosse preferível a depender apenas da vigilância. O texto reconhecia o que permanecia incerto: era quase impossível garantir absolutamente que nenhum aluno alcançaria conteúdo indesejado.

A AUP do provedor não era a política da escola

Ao estabelecer a conexão, o provedor deveria apresentar sua Acceptable Use Policy. Ela explicava usos aceitáveis e proibidos do serviço, incluindo atividades ilegais e, em algumas redes, usos comerciais.

O RFC 1578 dizia que uma política para toda a escola era essencial além da AUP. O provedor podia impor condições ao circuito que operava. Não podia decidir quem receberia conta de aluno, como um recurso entraria numa aula, quando seria necessária supervisão, qual consequência escolar seguiria uma violação ou como os pais participariam.

O acesso de casa deixava a passagem de responsabilidade visível. Mesmo que o provedor permitisse tecnicamente, a escola ainda teria de decidir se disponibilizaria a opção aos alunos. O documento recomendava uma discussão pública entre escola e comunidade, porque educadores e pais compartilhavam o acompanhamento do uso. Capacidade, autorização e responsabilidade não eram o mesmo registro.

Cada afirmação exigia sua própria evidência

Para demonstrar conexão, é preciso registrar modo de acesso, terminação, estado da linha e serviço alcançado. Para demonstrar capacidade, testar a aplicação a partir da sala, biblioteca e conta previstas. Para demonstrar formação, registrar participantes e tarefas que conseguem executar. Para demonstrar política, conservar decisor, versão, data e escopo. Para avaliar filtragem, testar as rotas cobertas e declarar as rotas de fora. Para investigar um evento, vincular conta, mensagem ou sessão, horário e resposta.

A fatura não comprova preparo do professor. Um ping não comprova filtragem do correio. A publicação de uma regra não comprova entendimento. Um bloqueio não comprova ausência de caminho alternativo. Um incidente não descreve todos os usuários.

O próprio RFC admitia sua natureza provisória. A Internet mudava depressa, e até referências escolhidas por estabilidade poderiam ficar desatualizadas. Atualizações manteriam o número FYI, mas receberiam outro número RFC. O guia não se colocava como autoridade permanente acima da operação local.

A escola ganhou conexão. A partir daí começava o trabalho que não cabia na fatura: decidir, formar, apoiar, observar e revisar sem deixar que uma única camada falasse por todas as outras.

Fontes