- O Protocolo Gopher da Internet 10 20 30 40 50 60 ---------+---------+---------+---------+---------+---------+-- Este documento foi traduzido do origial https://www.rfc-editor.org/rfc/rfc1436 com auxílio de ferramentas de tradução e revisado por xibolete. O Protocolo Gopher da Internet (protocolo distribuído de busca e recuperação de documentos) Status deste memorando Este memorando fornece informações para a comunidade da Internet. Ele não especifica um padrão de Internet. A distribuição deste memorando é ilimitada. Resumo O protocolo Internet Gopher foi projetado para pesquisa e recuperação distribuída de documentos. Este documento descreve o protocolo, lista algumas das implementações atualmente disponíveis e apresenta uma visão geral de como implementar novos aplicativos de cliente e servidor. Este documento foi adaptado do documento básico do protocolo Gopher da Internet publicado pela primeira vez pelo Microcomputer Center da Universidade de Minnesota em 1991. Sintese gopher, s.f. 1. Qualquer um dos vários mamíferos escavadores de cauda curta da família Geomyidae, da América do Norte. 2. (Coloquial americano) Nativo ou habitante de Minnesota: o Estado Gopher. 3. (Coloquial americano) Aquele que faz recados, realiza trabalhos estranhos, busca ou entrega documentos para a equipe do escritório. 4. (Tecnologia da computação) Software que segue um protocolo simples para navegar em uma Internet TCP/IP. O protocolo e o software Gopher da Internet seguem um modelo cliente-servidor. Esse protocolo pressupõe um fluxo de dados confiável; pressupõe-se TCP. Os servidores Gopher devem escutar na porta 70 (a porta 70 é atribuída ao Internet Gopher pela IANA). Os documentos residem em muitos servidores autônomos na Internet. Os usuários executam o software cliente em seus sistemasde desktop, conectando-se a um servidor e enviando a ele um seletor (uma linha de texto, que pode estar vazia) por meio de uma conexão TCP em uma porta bem conhecida. O servidor responde com um bloco de texto terminado por um ponto final em uma linha isolada e fecha a conexão. Nenhum estado é retido pelo servidor. Embora os documentos (e serviços) residam em muitos servidores, o software cliente Gopher apresenta aos usuários uma hierarquia de itens e diretórios muito parecida com um sistema de arquivos. A interface do Gopher foi projetada para se assemelhar a um sistema de arquivos, uma vez que um sistema de arquivos é um bom modelo para organizar documentos e serviços; o usuário vê o que equivale a um grande sistema de informações em rede contendo principalmente itens de documentos, itens de diretórios e itens de pesquisa (o último permite pesquisas de documentos em subconjuntos da base de informações). Os servidores retornam listas de diretórios ou documentos. Cada item em um diretório é identificado por um tipo (o tipo de objeto que o item é), um nome visível pelo usuário (usado para navegar e selecionar nas listagens), uma cadeia de caracteres seletora opaca (geralmente contendo um nome de caminho usado pelo host de destino para localizar o objeto desejado), um nome de host (qual host deve ser contatado para obter esse item) e um número de porta IP (a porta na qual o processo do servidor escuta as conexões). O usuário vê apenas o nome visível. O software cliente pode localizar e recuperar qualquer item pelo trio de seletor, nome de host e porta. Para usar um item de pesquisa, o cliente envia uma consulta a um tipo especial de servidor Gopher: um servidor de pesquisa. Nesse caso, o cliente envia a string do seletor (se houver) e a lista de palavras a serem combinadas. A resposta produz "listas de diretórios virtuais" que contêm itens que correspondem aos critérios de pesquisa. Existem servidores e clientes Gopher para todas as plataformas populares. Como o protocolo é tão esparso e simples, escrever servidores ou clientes é rápido e direto. 1. Introdução O protocolo Gopher da Internet foi projetado principalmente para atuar como um sistema distribuído de entrega de documentos. Embora os documentos (e serviços) residam em muitos servidores, o software cliente Gopher apresenta aos usuários uma hierarquia de itens e diretórios muito parecida com um sistema de arquivos. De fato, a interface do Gopher foi projetada para se assemelhar a um sistema de arquivos, já que um sistema de arquivos é um bom modelo para localizar documentos e serviços. Por que modelar um sistema de informações em todo o campus com base em um sistema de arquivos? Porvários motivos: (a) Um arranjo hierárquico de informações é familiar para muitos usuários. Os diretórios hierárquicos que contêm itens (como documentos, servidores e subdiretórios) são amplamente usados em quadros de avisos eletrônicos e outros sistemas de informações em todo o campus. As pessoas que acessam um servidor de informações de todo o campus esperam algum tipo de organização hierárquica das informações apresentadas. (b) Uma hierarquia no estilo de sistema de arquivos pode ser expressa em uma sintaxe simples. A sintaxe usada para o protocolo Gopher da Internet é facilmente compreensível e foi projetada para facilitar a depuração de servidores e clientes. Você pode usar o Telnet para simular as solicitações de um cliente Gopher da Internet e observar as respostas de um servidor. Não são necessárias ferramentas de software para fins especiais. Ao manter a sintaxe do protocolo cliente/servidor do sistema de pseudoarquivos simples, também podemos obter melhor desempenho para uma atividade muito comum do usuário: navegar pela hierarquia de diretórios. (c) Como o Gopher se originou em uma universidade, um dos objetivos era que os departamentos tivessem a opção de publicar informações a partir de seus computadores de mesa baratos e, como muitas das informações podem ser apresentadas como arquivos de texto simples organizados em diretórios, um protocolo modelado com base em um sistema de arquivos tem utilidade imediata. Como pode haver um mapeamento direto do sistema de arquivos no computador de mesa do usuário para a estrutura de diretórios publicada por meio do protocolo Gopher, o problema de escrever software de servidor para sistemas de mesa lentos é minimizado. (d) A metáfora de um sistema de arquivos é extensível. Ao atribuir um atributo "tipo" aos itens no sistema de pseudoarquivos, é possível acomodar documentos que não sejam documentos de texto simples. Os serviços de banco de dados complexos podem ser tratados como um tipo de item separado. Uma metáfora de sistema de arquivos não exclui pesquisas ou consultas ao estilo de banco de dados para acesso a documentos. Um tipo de servidor de pesquisa também é definido nesse pseudo-sistema de arquivos. Esses servidores retornam "diretórios virtuais" ou listas de documentos que correspondem aos critérios especificados pelo usuário. 2. O modelo do Internet Gopher Uma renderização BNF detalhada da sintaxe do Internet Gopher está disponível no apêndice... mas uma leitura atenta do apêndice pode não ser necessária para entender o protocolo Gopher da Internet. Em essência, o protocolo Gopher consiste em um cliente que se conecta a um servidor e enviar ao servidor um seletor (uma linha de texto, que pode estar vazia) por meio de uma conexão TCP. O servidor responde com um bloco de texto texto terminado com um ponto final em uma linha separada e fecha a conexão. Nenhum estado é retido pelo servidor entre as transações com um cliente. A natureza simples do protocolo decorre da necessidade de implementar servidores e clientes para os computadores desktop menores e lentos (Macs de 1 MB e máquinas DOS), de forma rápida e eficiente. Abaixo está um exemplo simples de uma interação cliente/servidor; as mais complexas serão tratadas posteriormente. Suponha que um servidor Gopher "bem conhecido" (isso pode ser duplicado, os detalhes serão discutidos mais adiante) escuta em uma porta bem conhecida do campus (como um servidor de nome de domínio). As únicas informações de configuração que o software cliente retém são o nome do servidor e o número da porta (neste exemplo, essa máquina é rawBits.micro.umn.edu e a porta é 70). No exemplo abaixo, o caractere F indica o caractere TAB. Cliente: {Abre conexão com rawBits.micro.umn.edu na porta 70} Servidor: {Aceita a conexão, mas não diz nada} Client: {Envia uma linha vazia: Significa “liste o que você tem”} Servidor: {Envia uma série de linhas, cada uma terminando com CR LF} 0About internet GopherFStuff:About usFrawBits.micro.umn.eduF70 1Around University of MinnesotaFZ,5692,AUMFunderdog.micro.umn.eduF70 1Microcomputer News & PricesFPrices/Fpserver.bookstore.umn.eduF70 1Courses, Schedules, CalendarsFFevents.ais.umn.eduF9120 1Student-Staff DirectoriesFFuinfo.ais.umn.eduF70 1Departmental PublicationsFStuff:DP:FrawBits.micro.umn.eduF70 {.....etc.....} . {Ponto em uma linha por si só} {Servidor fecha a conexão} O primeiro caractere de cada linha indica se a linha descreve um documento, diretório ou serviço de pesquisa (caracteres '0', '1', '7'; há mais alguns desses caracteres descritos posteriormente). Os caracteres seguintes até a tabulação formam uma string de exibição do usuário a ser exibida ao usuário para uso na seleção desse documento (ou diretório) para listagem. O primeiro caractere da linha está realmente definindo o tipo de item descrito nessa linha. Em quase todos os casos, o software cliente Gopher dará aos usuários algum tipo de ideia sobre que tipo de item é esse (exibindo um ícone, uma tag de texto curto ou algo semelhante). Os caracteres após a tabulação, até a próxima tabulação, formam uma string seletora que o software cliente deve enviar ao servidor para recuperar o documento (ou listagem de diretório). A string do seletor não deve significar nada para o software cliente ela nunca deve ser modificada pelo cliente. Na prática, a string do seletor geralmente é um nome de caminho ou outro seletor de arquivo usado pelo servidor para localizar o item desejado. Os próximos dois campos delimitados por tabulação indicam o nome de domínio do host que possui esse documento (ou diretório) e a porta à qual se conectar. Se ainda houver outros campos delimitados por tabulação, o cliente básico do Gopher deverá ignorá-los. Um CR LF indica o fim do item. No exemplo, a linha 1 descreve um documento que o usuário verá como "About Internet Gopher". Para recuperar esse documento, o software cliente deve enviar a string de recuperação: "Stuff:About us" para rawBits.micro.umn.edu na porta 70. Se o cliente fizer isso, o servidor responderá com o conteúdo do documento, terminado por um ponto final em uma linha separada. Um cliente pode apresentar ao usuário uma visão do mundo semelhante à seguinte lista de itens: About Internet Gopher Around the University of Minnesota... Microcomputer News & Prices... Courses, Schedules, Calendars... Student-Staff Directories... Departmental Publications.. Nesse caso, os diretórios são exibidos com reticências e os arquivos são exibidos sem nenhuma. Entretanto, dependendo da plataforma para a qual o cliente foi escrito e do gosto do autor, os tipos de itens podem ser denotados por outras tags de texto ou por ícones. Por exemplo, o cliente UNIX baseado em curses, exibe diretórios com uma barra (/) após o nome; os clientes Macintosh exibem os diretórios ao lado de um ícone de uma pasta. O usuário não sabe ou não se importa que os itens a serem selecionados possam residir em muitas máquinas diferentes em qualquer lugar da Internet. Suponha que o usuário selecione a linha "Microcomputer News & Prices...". Isso parece ser um diretório e, portanto, o usuário espera ver o conteúdo do diretório ao solicitar que ele seja buscado. As linhas a seguir ilustram a interação cliente-servidor que se segue: Cliente: (Conecta-se a pserver.bookstore.umn.edu na porta 70) Servidor: (Aceita a conexão, mas não diz nada) Cliente: Prices/ (Envia a string mágica terminada por CRLF) Servidor: (Envia uma série de linhas, cada uma terminando com CR LF) 0About PricesFPrices/AboutusFpserver.bookstore.umn.eduF70 0Macintosh PricesFPrices/MacFpserver.bookstore.umn.eduF70 0IBM PreçosFPrices/IckFpserver.bookstore.umn.eduF70 0Printer & Peripheral PricesFPrices/PPPFpserver.bookstore.umn.eduF70 (.....etc.....) . (Ponto final em uma linha por si só) (O servidor fecha a conexão) 3. Mais detalhes 3.1 Localização de serviços Os documentos (ou outros serviços que podem ser vistos, em última análise, como documentos, como uma lista telefônica de alunos e funcionários) são vinculados à máquina em que estão pelo trio de string de seletor, nome de domínio da máquina e porta IP. Presume-se que haverá um servidor de nível superior ou raiz bem conhecido para uma instituição ou campus. As informações nesse servidor podem ser duplicadas por um ou mais servidores para evitar um único ponto de falha e para distribuir a carga por vários servidores. Os departamentos que desejarem criar seus próprios servidores departamentais precisam registrar o nome da máquina e a porta com os administradores do servidor Gopher de nível superior, da mesma forma que registram um nome de máquina no servidor de nomes de domínio do campus. Uma entrada que aponte para o servidor departamental será então criada no servidor de nível superior. Isso garante que os usuários possam navegar pelo que equivale a um sistema de arquivos hierárquico virtual com uma raiz bem conhecida para qualquer servidor do campus, se assim desejarem. Observe que não é necessário que um departamento registre servidores secundários no servidor central de nível superior; eles podem simplesmente colocar um link para os servidores secundários em seus próprios servidores primários. De fato, eles podem colocar links para quaisquer servidores que desejarem em seu próprio servidor, criando assim uma visão personalizada do universo de informações do Gopher. Os links podem, é claro, apontar de volta para o servidor de nível superior. O sistema de arquivos virtual (em rede) é, portanto, uma estrutura gráfica arbitrária e não necessariamente uma árvore com raiz. O nó de nível superior é apenas um ponto de entrada conveniente e bem conhecido. Um conjunto de servidores Gopher conectados dessa maneira pode funcionar como um sistema de informações em todo o campus. Os servidores podem, é claro, apontar links para outros servidores que não sejam secundários. De fato, os servidores podem apontar para outros servidores que ofereçam serviços úteis em qualquer lugar da Internet.Visto dessa forma, o Gopher pode ser considerado como um sistema de informações em toda a Internet. 3.2 Portabilidade e nomenclatura do servidor Recomenda-se que todos os servidores registrados tenham nomes de alias (sistema de nomes de domínio CNAME) que sejam usados pelos clientes do Gopher para localizá-los. Os links para esses servidores devem usar esses nomes de alias em vez dos nomes primários. Se as informações precisarem ser movidas de uma máquina para outra, uma simples alteração do alias do sistema de nomes de domínio (CNAME) permite que isso ocorra sem nenhuma reconfiguração de clientes no campo. Em resumo, o sistema de nomes de domínio pode ser usado para remapear um servidor para um novo endereço. Não há nada que impeça que servidores ou serviços secundários sejam executados em servidores ou portas nomeados de outra além do 70, mas esses devem ser acessíveis por meio de um servidor primário. 3.3 Contato com administradores de servidores Recomenda-se que todo administrador de servidor tenha um documento chamado algo como: “Sobre o servidor Gopher da Bogus University” como o primeiro item no diretório de nível superior do servidor. Nesse documento deve conter uma breve descrição do que o servidor contém, bem como o nome, o endereço, o telefone e o endereço de e-mail da pessoa que administra o servidor. Isso proporciona uma maneira de os usuários entrarem em contato com o administrador de um servidor com informações imprecisas ou que não esteja funcionando corretamente. Recomenda-se também que os administradores coloquem a data da última atualização nos arquivos para os quais essas informações sejam importantes para os usuários. 3.4 Adição modular de serviços O primeiro caractere de cada linha em uma lista de diretórios fornecida pelo servidor indica se o item é um arquivo (caractere '0'), um diretório (caractere '1') ou uma pesquisa (caractere '7'). Esse é o conjunto conjunto básico de tipos de itens no protocolo Gopher. É desejável que os clientes possam usar serviços diferentes e falar protocolos diferentes (simples, como o finger; outros, como o serviço de agenda telefônica CSO ou Telnet, ou serviço de diretório X.500), conforme a necessidade. O serviço de lista telefônica CSO é um sistema de lista telefônica cliente/servidor normalmente usado em universidades para publicar nomes, endereços de e-mail e assim por diante. O software de lista telefônica CSO foi desenvolvido na Universidade de Illinois e às vezes também é chamado de ph ou qi. Por exemplo, se uma listagem de diretório fornecida pelo servidor marcar um determinado item com o caractere de tipo '2', isso significa que, para usar esse item, o cliente deve falar o protocolo CSO. Isso elimina a necessidade de ser capaz de antecipar todas as necessidades futuras e conectá-las ao protocolo básico do Internet Gopher; isso mantém o protocolo básico extremamente simples. Por outro lado, subconjuntos de outros esquemas de recuperação de documentos podem ser mapeados no protocolo Gopher por meio de "gateway-servers". Exemplos de tais servidores incluem gateways Gopher-para-FTP, gateways Gopher-para-archie, gateways Gopher-para-WAIS etc. Há várias vantagens nesses mecanismos. Primeiro, um servidor relativamente poderoso herda a inteligência e o trabalho, em vez de um sistema desktop mais modesto e barato que normalmente executa o software cliente ou o software básico do servidor. Igualmente importante, os clientes não precisam ser modificados para aproveitar um novo recurso. 3.5 Criação de clientes Um cliente simplesmente envia a string de recuperação para um servidor se quiser recuperar um documento ou visualizar o conteúdo de um diretório. É claro, cada host pode ter ponteiros para outros hosts, resultando em um “gráfico” (não necessariamente uma árvore enraizada) de hosts. O software cliente pode salvar (ou melhor, “empilhar”) os locais que visitou em busca de um documento. Portanto, o usuário pode sair do local atual a desempilhando. Como alternativa, um cliente com capacidade de várias janelas pode simplesmente exibir mais de um diretório ou documento ao mesmo tempo. Um cliente inteligente poderia armazenar em cache o conteúdo dos diretórios visitados (em vez de apenas o descritor de item do diretório), evitando assim transações de rede se as informações tiverem sido recuperadas anteriormente. Se um cliente não entender o que é um item, digamos, do tipo 'B' (não um item principal), ele poderá simplesmente ignorar o item na listagem do diretório e o usuário nem precisará vê-lo. Como alternativa, o item poderia ser exibido como um tipo desconhecido. É provável que os servidores de nível superior ou primários de um campus recebam mais tráfego do que os servidores secundários, e seria menos tolerável que esses servidores primários fiquem fora do ar por muito tempo. Portanto, faz sentido “clonar” esses servidores importantes e criar clientes que possam escolher aleatoriamente entre dois desses servidores primários equivalentes quando se conectam pela primeira vez (para equilibrar a carga do servidor), mudando para um deles se o outro parecer estar inativo. De fato, as implementações de clientes inteligentes fazem esse clone de servidor e balanceamento de carga. Como alternativa, pode fazer sentido fazer com que o sistema de nomes de domínio retorne um do conjunto de endereços IP redundantes do servidor para equilibrar a carga entre conjuntos redundantes de servidores importantes. 3.6 Criação de servidores Gopher comuns na Internet A string de recuperação enviada ao servidor pode ser um caminho para um arquivo ou diretório. Pode ser o nome de um script, um aplicativo ou até mesmo uma consulta que gera o documento ou diretório retornado. O servidor usa a string que recebe até um CR-LF ou uma TAB, o que vier primeiro. Toda a inteligência é transportada pela implementação do servidor, e não pelo protocolo. O que você constrói em servidores mais exóticos fica a seu critério. As implementações de servidor podem crescer conforme as necessidades e o tempo permitir. 3.7 Servidores para fins especiais Há dois tipos de servidores especiais (além do servidor Gopher normal) também discutidos abaixo: 1. Uma listagem de diretório de servidor pode apontar para um servidor de nomes CSO (o servidor retorna um caractere de tipo '2') para permitir um serviço de lista telefônica de alunos e funcionários do campus. Isso pode aparecer na lista de opções do do usuário, talvez precedido pelo ícone de uma lista telefônica. Se esse item for selecionado, o software cliente deverá recorrer a um protocolo de servidor de nomes CSO puro quando se conectar ao host apropriado. 2. Um servidor também pode apontar para um “servidor de pesquisa” (retorna um primeiro caractere '7'). Esses servidores podem implementar o recurso de pesquisa em toda a rede (ou sub-rede) do campus. Os servidores de pesquisa mais comuns mantêm índices de texto completo sobre o conteúdo de documentos de texto mantidos por algum subconjunto de servidores Gopher. Esse “servidor de pesquisa de texto completo” responde às solicitações do cliente com uma lista de todos os documentos que contêm uma ou mais palavras (os critérios de pesquisa). O cliente envia ao servidor a string de seleção, uma guia e a string de pesquisa (palavras a serem pesquisadas). Se a string de seleção estiver vazia, o cliente envia apenas a string de pesquisa. O servidor retorna o equivalente a de uma listagem de diretório para os documentos que correspondem aos critérios de pesquisa. Os espaços entre as palavras geralmente são ANDs booleanos (Es lógicos) implícitos (embora em diferentes implementações ou tipos de pesquisa, isso pode não ser necessariamente seja verdadeiro). O acréscimo do CSO existe por motivos históricos: na época do projeto, os servidores de listas telefônicas do campus da Universidade de Minnesota usavam o protocolo CSO e parecia que simplesmente as engoliam. O servidor de índice é, no entanto, muito parecido com o Gopher em seu espírito, embora com uma pequena embora com uma pequena alteração no significado da string seletora. Os servidores de índice são um local natural para incorporar gateways aos serviços WAIS e WHOIS. 3.7.1 Criação de servidores CSO Uma implementação do servidor de nomes de domínios do CSO para UNIX e a documentação associada está disponível por ftp anônimo em uxa.cso.uiuc.edu. Nós não Prevemos implementá-la em outras máquinas. 3.7.2 Criação de servidores de pesquisa de texto completo Um servidor de pesquisa de texto completo é um servidor para fins especiais que conhece o sobre o esquema Gopher para recuperar documentos. Esses servidores mantêm um índice de texto completo do conteúdo de documentos de texto simples em servidores Gopher em algum domínio específico. Um servidor de pesquisa de texto completo do Gopher foi implementado usando várias NeXTstations porque era fácil de aproveitar o mecanismo de pesquisa/índice de texto completo incorporado ao software do sistema software do sistema NeXT. Um servidor de pesquisa para sistemas UNIX genéricos baseadono mecanismo de pesquisa WAIS de domínio público, também está disponível e atualmente uma parte opcional do servidor UNIX gopher. Além disso, pelo menos uma implementação do servidor gopher incorpora um gateway para servidores WAIS, apresentando os servidores WAIS ao gopherspace como servidores de pesquisa de texto completo. Os servidores de gateway gopher<->WAIS fazem o trabalho de tradução do protocolo gopher para o WAIS, de modo que os clientes gopher não modificados possam acessar os servidores WAIS por meio do servidor de gateway. Ao usar vários servidores de índice (em vez de um servidor de índice monolítico), os índices podem ser pesquisados em paralelo (embora o software cliente não esteja ciente disso). Embora a manutenção de índices de texto completo de documentos distribuídos em muitas máquinas pode parecer uma tarefa assustadora, a tarefa pode ser dividida em partes menores (atualizar apenas uma parte dos dos índices, pesquisar vários índices parciais em paralelo) para que seja gerenciável. 3.8 Caracteres de tipo de item O software cliente decide quais itens estão disponíveis observando o primeiro caractere de cada linha em uma listagem de diretório. Aumentar essa lista pode estender o protocolo. Segue uma lista de caracteres definidos de tipo de item definida a seguir: 0 Item é um arquivo 1 Item é um diretório 2 O item é um servidor de lista telefônica CSO 3 Erro 4 O item é um arquivo BinHexed do Macintosh. 5 O item é um arquivo binário do DOS de algum tipo. O cliente deve ler até o fechamento da conexão TCP. Cuidado. 6 O item é um arquivo UNIX uuencoded. 7 Item é um servidor de pesquisa de índice. 8 O item aponta para uma sessão telnet baseada em texto. 9 O item é um arquivo binário! O cliente deve ler até o fechamento da conexão TCP. Cuidado. + Item é um servidor redundante T Item aponta para uma sessão tn3270 baseada em texto. g Item é um arquivo gráfico no formato GIF. I Item é algum tipo de arquivo de imagem. O cliente decide como exibir. Os caracteres de '0' a 'Z' são reservados. Os experimentos locais devem usar outros caracteres. Extensões específicas da máquina não são incentivadas. Observe que, para o tipo 5 ou o tipo 9, o cliente deve estar preparado para ler até o fechamento da conexão. Não haverá ponto final do arquivo; o conteúdo desses arquivos é binário e o cliente deve decidir o que fazer com eles com base, talvez, na extensão .xxx. 3.9 Strings de exibição do usuário e strings de seleção de servidor As strings de exibição do usuário devem ser exibidas em uma linha em uma tela típica para o prazer de visualização do usuário. Embora muitas telas possam acomodar linhas de 80 caracteres, é necessário algum espaço para exibir uma tag de algum tipo para informar ao usuário que tipo de item é esse. Por esse motivo isso, a string de exibição do usuário deve ter menos de 70 caracteres. Os clientes podem truncá-la em um tamanho que lhes seja conveniente. 4. A simplicidade é intencional Na medida do possível, desejamos que todos os novos recursos sejam transportados como novos protocolos que ficarão ocultos atrás de novos tipos de documentos. A filosofia do Gopher na Internet é a seguinte (a) A inteligência é mantida pelo servidor. Os clientes têm a opção de poder acessar novos tipos de documentos (diferentes, outros tipos de servidores) simplesmente reconhecendo o caractere do tipo de documento. A inteligência adicional a ser suportada pelo protocolo deve ser minimizada. (b) O servidor bem preparado deve enviar "texto" (a menos que um arquivo deva ser transferido como binário bruto). Esse texto deve incluir tabs, formfeeds, frufru? Provavelmente não, mas servidores mais desleixados provavelmente os enviarão de qualquer forma. Os editores de documentos devem receber ferramentas simples (filtros) que os alertem se houver caracteres nos documentos que desejam publicar e a oportunidade de remover os caracteres questionáveis; o editor pode se recusar. (c) O cliente bem preparado deve fazer algo razoável com caracteres estranhos recebidos no texto; filtrá-los, deixá-los pra lá, o que for. Apêndice NQBNF (Not Quite BNF) de Paul para o protocolo Gopher. Observação: trata-se de BNF modificado (conforme usado pelo pessoal do Pascal) com alguns modificadores em inglês. Os elementos entre "{}" podem ser repetido zero ou mais vezes. Os elementos em "[]" denotam um conjunto de itens. O operador "-" indica a subtração de um conjunto. Entidade de diretório CR-LF ::= Caractere ASCII Carriage Return seguido por um caractere Line Feed Tab ::= Caractere de tabulação ASCII. NUL ::= Caractere ASCII NUL. UNASCII ::= ASCII - [Tab CR-LF NUL]. Lastline ::= '.'CR-LF. TextBlock ::= Bloco de texto ASCII que não contém o padrão Lastline. Type ::= UNASCII. RedType ::= '+'. User_Name ::= {UNASCII}. Selector ::= {UNASCII}. Host ::= {{UNASCII - ['.']} '.'} {UNASCII - ['.']}. Observação: esse é um nome de domínio totalmente qualificado, conforme definido na RFC 1034. (por exemplo, gopher.micro.umn.edu) Hosts que têm um CR-LF TAB ou NUL em seu nome recebem o que merecem. Digit ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | 8' | '9' . DigitSeq ::= dígito {digit}. Port ::= DigitSeq. Observação: Port corresponde ao número da porta TCP, seu valor deve estar deve estar no intervalo [0.. 65535]; a porta 70 é oficialmente atribuída para o gopher. DirEntity ::= Type User_Name Tab Selector Tab Host Tab Port CR-LF {RedType User_Name Tab Selector Tab Host Tab Port CR-LF} Observações: É altamente recomendável que o campo User_Name contenha somente caracteres imprimíveis, pois muitos clientes diferentes o usarão o campo. Entretanto, se forem usados caracteres de oito bits, os caracteres devem estar em conformidade com o conjunto de caracteres ISO Latin1. O comprimento da linha exibível do usuário deve ter menos de 70 caracteres; linhas mais longas podem não caber em algumas telas. A string do seletor não deve ter mais de 255 caracteres. Entidade Menu Menu ::= {DirEntity} Lastline. Transação de menu (item do tipo 1) C: Abre a conexão S: Aceita a conexão C: Envia a string do seletor S: Envia a entidade do menu A conexão é fechada pelo cliente ou pelo servidor (normalmente o servidor). Entidade Textfile TextFile ::= {TextBlock} Lastline Observação: as linhas que começam com pontos devem ser precedidas de um ponto extra para garantir que a transmissão não seja encerrada antes do tempo. O cliente deve retirar os pontos extras no início da linha. Transação TextFile (item do Tipo 0) C: Abre a conexão. S: Aceita a conexão C: Envia a string do seletor. S: Envia a entidade TextFile. A conexão é fechada pelo cliente ou pelo servidor (normalmente o servidor). Observação: O cliente deve estar preparado para o fato do servidor fechar a conexão sem enviar a Lastline. Isso permite que o cliente cliente use servidores fingerd. Transação de pesquisa de texto completo (item do tipo 7) Word ::= {UNASCII - ' '} BoolOp ::= 'and' | 'or' | 'not' | SPACE SearchStr ::= Word {{SPACE BoolOp} SPACE Word} C: Abre a conexão. C: Envia string seletora, tabulação, cadeia de caracteres de pesquisa. S: Envia a entidade do menu. Observação: Na ausência de operadores “and”, “or” ou “not”, um SPACE é considerado como um operador “e” implícito. A expressão é avaliada da esquerda para a direita. Além disso, nem todos os mecanismos de busca ou gateways de pesquisa implementados atualmente têm os operadores booleanos implementados. Transação de arquivo binário (item do tipo 9 ou 5) C: Abre a conexão. S: Aceita a conexão. C: Envia a string do seletor. S: Envia um arquivo binário e fecha a conexão quando concluído. Significado sintático para entidades de diretório O cliente deve interpretar o campo type da seguinte forma: 0 O item é uma Entidade TextFile. O cliente deve usar uma transação TextFile. 1 O item é uma entidade de menu. O cliente deve usar uma transação de menu. 2 A informação se aplica a uma entidade de lista telefônica CSO. O cliente deve usar o protocolo CSO. 3 Sinaliza uma condição de erro. 4 O item é um arquivo Macintosh codificado no formato BINHEX 5 O item é algum tipo de arquivo binário do PC-DOS. O cliente decide. 6 O item é um arquivo uuencoded. 7 A informação se aplica a um servidor de índice. O cliente deve usar uma transação FullText Search. 8 As informações se aplicam a uma sessão Telnet. Conecte-se a um determinado host em uma determinada porta. O nome para fazer login como o host está na string do seletor. 9 O item é um arquivo binário. O cliente deve decidir o que fazer com ele. + As informações se aplicam a um servidor duplicado. As informações contidas nele são uma duplicata do servidor principal. O servidor primário é definido como a última DirEntity que possui um campo campo “Type”. O cliente deve usar a transação conforme definido pelo campo Type do servidor primário. g Item é um arquivo gráfico GIF. I Item é algum tipo de arquivo de imagem. O cliente é quem decide. T As informações se aplicam a uma sessão telnet baseada em tn3270. Conectar-se a um determinado host em uma determinada porta. O nome para fazer login como o host está na string do seletor. Considerações sobre segurança As questões de segurança não são discutidas neste memorando. Endereços dos autores Farhad Anklesaria Computer and Information Services, University of Minnesota Room 152 Shepherd Labs 100 Union Street SE Minneapolis, MN 55455 Telefone: (612) 625 1300 Email: fxa@boombox.micro.umn.edu Mark McCahill Computer and Information Services, University of Minnesota Room 152 Shepherd Labs 100 Union Street SE Minneapolis, MN 55455 Telefone: (612) 625 1300 EMail: mpm@boombox.micro.umn.edu Paul Lindner Computer and Information Services, University of Minnesota Room 152 Shepherd Labs 100 Union Street SE Minneapolis, MN 55455 Telefone: (612) 625 1300 EMail: lindner@boombox.micro.umn.edu David Johnson Computer and Information Services, University of Minnesota Room 152 Shepherd Labs 100 Union Street SE Minneapolis, MN 55455 Telefone: (612) 625 1300 EMail: dmj@boombox.micro.umn.edu Daniel Torrey Computer and Information Services, University of Minnesota Room 152 Shepherd Labs 100 Union Street SE Minneapolis, MN 55455 Telefone: (612) 625 1300 EMail: daniel@boombox.micro.umn.edu Bob Alberti Computer and Information Services, University of Minnesota Room 152 Shepherd Labs 100 Union Street SE Minneapolis, MN 55455 Telefone: (612) 625 1300 EMail: alberti@boombox.micro.umn.edu