Resumo

  • A RFC 3380 avaliava uma solicitação Set-Job-Attributes compatível como um estado completo proposto, e não como campos que poderiam ser aplicados parcialmente.
  • Um atributo ou valor incompatível exigia rejeitar a solicitação inteira e preservar o Job; isso não cancelava o trabalho nem comprovava a saída física.

Em setembro de 2002, o IPP ganhou um limite administrativo mais explícito. Um usuário ou operador podia perceber, depois do envio, que faltava uma instrução de acabamento. A RFC 3380 ofereceu uma alternativa opcional a cancelar e reenviar: alterar atributos do objeto Job existente.

A impressora precisava avaliar os valores propostos junto com os atributos que o cliente deixava intactos. A pergunta era contrafactual: um novo trabalho com esse conjunto final seria aceito com ipp-attribute-fidelity=true? Se sim, a alteração deveria ser aceita. Caso contrário, deveria ser recusada e o Job existente permanecer sem mudança. Um atributo não suportado, não configurável ou conflitante não podia ser simplesmente descartado enquanto os demais eram aplicados. O pedido era tudo ou nada.

Isso evitava que o cliente confundisse um trabalho parcialmente alterado com o estado solicitado. A resposta podia apontar quais atributos falharam, enquanto o objeto preservava o estado anterior. Autorização era uma verificação separada: o solicitante autenticado precisava ser o dono do Job, operador ou administrador. Ter permissão para pedir não tornava válida uma combinação incompatível.

A RFC também definiu atualização atômica para atributos da impressora e incluiu Get-Printer-Supported-Values para descobrir valores aceitos em certos atributos configuráveis. printer-xri-supported permitia atualizar juntas descrições relacionadas de URI, autenticação e segurança. Mas as operações Set eram opcionais. A norma define o contrato, não prova que uma impressora específica o implementou, que um cliente o usou ou que uma página foi impressa.

A RFC 3196 trata de outro momento: quando a impressora pode responder definitivamente após receber os dados do documento. A RFC 3380 trata da alteração dos atributos do Job. Uma atualização aceita ou rejeitada não prova recebimento completo, processamento nem impressão. O evento do protocolo registra uma mudança de estado, não um resultado físico. Fontes primárias: RFC 3380, RFC 2911 e RFC 3196. A extensão era opcional; os textos não provam adoção nem interoperabilidade.

Fontes