Resumo

  • O RFC 1545, Experimental em novembro de 1993, propôs LPRT e LPSV para incluir família de endereços e comprimentos declarados do host e da porta. O antigo PORT usava seis campos decimais: quatro para o host e dois para a porta.
  • A resposta 228 indicava modo passivo com endereço longo; 521 informava que o servidor compreendia a ordem, mas não atendia à família solicitada. O RFC 1639 substituiu a primeira versão em junho de 1994 e especificou outras famílias de rede e interfaces de transporte.

A bagagem parou no guichê

O FTP trabalha com duas conexões. Uma carrega comandos e respostas; a outra transporta o arquivo ou a listagem. No RFC 959, PORT informa ao outro lado o endereço da conexão de dados. Seu argumento parece uma etiqueta modesta: h1,h2,h3,h4,p1,p2. Quatro valores de um octeto formam o endereço de host de 32 bits; dois formam a porta TCP de 16 bits. Todos são escritos como números decimais separados por vírgulas. Em IPv4 sobre TCP, a etiqueta dava conta do recado.

O problema apareceu quando a rede começou a planejar outros tamanhos de endereço e outros meios de transporte. Uma arquitetura pode admitir um endereço maior ou de comprimento variável; o programa antigo ainda precisa enunciá-lo ao parceiro. O FTP podia continuar falando no canal de controle e, na hora de combinar o canal de dados, descobrir que o campo destinado ao host só tinha quatro casas. Era uma limitação escrita pela aplicação, localizada antes do envio do primeiro byte do arquivo.

David Piscitello tratou dessa borda no RFC 1545, de novembro de 1993. O título FTP Operation Over Big Address Records rendeu FOOBAR, sigla que parece ter saído de um exemplo provisório. A ordem LPRT era concreta: primeiro o identificador da família de endereços, depois o comprimento do endereço de host, o host, o comprimento do endereço de porta e a porta. Cada valor continuava representado como octeto decimal sem sinal, com vírgulas entre eles. Agora a própria mensagem dizia quantas partes esperar e a que família pertenciam.

Do outro lado havia o modo passivo. LPSV pedia que o servidor escutasse numa porta de dados e respondesse com 228 Entering Long Passive Mode, incluindo família, comprimentos, host e porta. Abrir espaço só na ordem enviada pelo cliente teria deixado a resposta do servidor no corredor estreito. A proposta estendeu as duas direções da conversa que prepara o canal de dados.

O código 521 acrescentou uma distinção útil. Um servidor podia reconhecer as novas ordens e ainda não oferecer a família pedida. Ele responderia com a lista das famílias que sabia atender. 500 e 501 continuavam ligados a erros de sintaxe. Uma coisa era a frase estar malformada; outra, o par ler a frase e não possuir aquela ligação de rede. Com 521, os extremos recebiam informação para tentar uma opção disponível.

O cardápio de 1993 citava IP, ST Datagram Mode, SIP, TP/IX, PIP e TUBA. Eram alternativas que estavam em discussão, vistas pela lente do texto. Por que declarar também o comprimento da porta? O próprio RFC apontava o TP/IX, cujos seletores de transporte podiam ser maiores que os dezesseis bits da porta TCP. Resolver a largura do host mantendo estreita a outra metade da etiqueta criaria o próximo aperto. A proposta até permitia usar famílias diferentes nas conexões de comando e de dados. Uma mudança de arquitetura podia acontecer aos poucos e em arranjos mistos.

Em junho de 1994, o RFC 1639 tornou o RFC 1545 obsoleto e refinou o mecanismo. Reservou os valores de família 0 a 15 para números de versão relacionados a IP; de 16 a 255 ficavam disponíveis para outros protocolos de rede atribuídos pela IANA. Novell IPX aparecia no valor 16. A revisão também tratou explicitamente de FTP sobre interfaces de transporte além de TCP. O livro de endereços ficou preparado para mais de uma rua e mais de um tipo de veículo.

Tudo isso saiu de seis números separados por vírgulas. Quando o FTP adotou PORT h1,h2,h3,h4,p1,p2, uma escolha sobre IPv4 e TCP entrou na gramática permanente da aplicação. Os debates sobre o futuro da Internet podiam ocupar páginas de arquitetura; a transferência de arquivos ainda precisava passar pelo pequeno guichê do canal de dados. FOOBAR ampliou o formulário e escreveu nele o que antes ficava implícito.