Resumo

  • A RFC 3196 deixava inicialmente cada implementação decidir se receberia o documento inteiro antes da resposta final de Print-Job. O Erratum técnico 2924 eliminou essa margem: todos os dados precisam ser aceitos primeiro.
  • A exigência trata da resposta IPP final, tanto de sucesso quanto de erro. 100 Continue, um erro de transporte antecipado, a criação do trabalho e a impressão física são fatos diferentes.

A resposta veio antes do documento

O Internet Printing Protocol (IPP) foi pensado para que a impressão funcionasse como serviço de rede. O cliente envia uma operação por HTTP e, em Print-Job, o próprio documento segue no corpo da requisição. A impressora retorna um status IPP e, quando cria um trabalho, pode fornecer identificadores para consultas posteriores. O fluxo deixa uma questão prática: quando o servidor pode afirmar o resultado de uma solicitação cujo corpo ainda está em trânsito?

Publicada em novembro de 2001, a RFC 3196 era um guia de implementação do IPP/1.1. Na versão original, cabia à implementação decidir se aceitava todo o documento antes de responder de forma definitiva. Em 2011, o Erratum 2924 substituiu essa frase: a impressora DEVE receber todos os dados do documento antes de retornar a resposta final de sucesso ou erro. A mudança não criou um novo recurso de impressão. Tornou mais claro o significado da resposta final quando a requisição inclui um documento que pode demorar a chegar.

Isso importa especialmente em envios em fluxo. Se a aplicação informa um resultado enquanto ainda há dados sendo enviados, o cliente não sabe se o restante foi consumido, se há um trabalho criado ou se deve tentar novamente. Para a resposta IPP final, o erratum coloca esse limite do lado da impressora: primeiro a recepção completa; depois, a resposta.

Três confirmações, três significados

O alcance da regra é específico. 100 Continue é uma resposta HTTP provisória que autoriza o cliente a prosseguir com o corpo. Não significa que a operação IPP teve sucesso. Em certas situações, HTTP permite uma resposta final antecipada de erro quando o método não será executado; o tratamento do corpo e da conexão é uma questão de transporte. O erratum não declara que todo sinal antecipado seja uma violação.

Uma resposta bem-sucedida de Print-Job tampouco prova que uma página saiu da impressora. Ela pode trazer job-id e job-uri para o cliente consultar o estado mais tarde. As RFCs 8010 e 8011, de 2017, atualizaram e substituíram as RFCs 2910 e 2911, mantendo distintos o transporte HTTP, a operação IPP e o ciclo de vida do trabalho. Receber o documento, aceitar o trabalho, processá-lo, imprimir e entregar a folha são etapas separadas.

O registro é claro sobre a correção, mas não sobre a adoção. A RFC 3196 é Informational, não uma nova especificação de protocolo no standards track. O editor das RFCs classifica o Erratum 2924 como técnico; Michael Sweet o relatou em agosto de 2011 e Peter Saint-Andre o verificou em novembro. Esses documentos não mostram quais produtos adotaram a mudança, nem descrevem uma falha concreta causada pelo texto antigo. Transformar a correção em uma história de incidente seria ir além das evidências.

A lição é perguntar: qual camada confirmou exatamente o quê? O início de uma transferência não prova o recebimento do documento inteiro. Um identificador de trabalho não prova que o papel foi impresso. O erratum fecha uma ambiguidade delimitada, sem prometer resolver as demais.

Fontes

As fontes documentam a regra e seu histórico editorial, não a adoção por produtos, o desempenho medido, a prevalência operacional, uma falha específica, armazenamento durável ou a saída física do papel.