Resumo

  • O RFC 3382 acrescentou ao IPP uma sintaxe opcional para reunir membros nomeados de tipos diferentes em um só valor, inclusive coleções aninhadas e futuros membros opcionais.
  • A ordem não era normativa: uma impressora podia devolver os membros em outra sequência, de modo que nomes únicos e limites de coleção, não posições, tinham de sustentar o significado.

Um cliente envia três membros. A impressora devolve os mesmos três, mas muda sua ordem. Quem identifica o segundo valor apenas por ser o segundo verá corrupção. Quem segue o RFC 3382 verificará nome, sintaxe, valor e o limite que os mantém associados. A representação mudou; a estrutura não necessariamente mudou.

Publicado em setembro de 2002 na trilha de padrões, o documento preencheu uma lacuna do Internet Printing Protocol. O IPP já representava muitos valores simples e repetidos, porém não oferecia uma forma geral de dizer que atributos heterogêneos compunham uma unidade. A comparação com um dicionário PostScript ou um Map de Java descrevia associação por nome, não um transplante completo de objetos de programação.

Uma coleção continha um ou mais atributos membros. Cada membro preservava nome e sintaxe próprios: inteiro, palavra-chave, intervalo ou outro tipo IPP. Um membro podia ser outra coleção ou um conjunto de coleções. O recipiente não apagava diferenças; declarava que valores distintos pertenciam à mesma estrutura.

Pertencer junto não significava ocupar um lugar fixo. Os membros podiam aparecer em qualquer ordem, e a impressora podia armazená-los e devolvê-los de maneira diferente da requisição. Portanto, “segundo” não podia equivaler a altura e “último” não podia equivaler a cor. A posição era circunstância de serialização; a identidade vinha do nome dentro do escopo.

O documento que definisse uma coleção real tinha de informar nome, cardinalidade, contexto, descoberta de membros suportados e, para cada membro, requisito, sintaxe, semântica, restrições, valores aceitos e padrão. O RFC forneceu uma gramática reutilizável, mas não liberou futuros autores do trabalho de definir contratos precisos.

Nomes precisavam ser únicos dentro da definição. O mesmo nome podia existir em outra coleção ou no espaço IPP maior, pois o limite determinava o escopo. Essa combinação permitia reutilizar vocabulário sem introduzir ambiguidade dentro de um valor.

Dois membros com o mesmo nome tornavam a coleção malformada. Clientes não deviam enviá-la, e impressoras não deviam retorná-la. Ao receber tal requisição, uma impressora podia rejeitá-la ou aceitá-la usando apenas uma duplicata, conforme a implementação. O RFC não estabeleceu “primeiro vence” nem “último vence”. A ordem não corrigia a perda de unicidade.

O aninhamento ampliava a expressão, mas não criava um documento sem regras. Não havia limite único para o tamanho total da coleção, enquanto cada membro continuava preso aos limites de sua sintaxe. As folhas ainda eram valores IPP, e a estrutura admitida ainda dependia de definição publicada.

Membros opcionais também permitiam evolução. Uma implementação antiga podia não entender uma adição, mas precisava indicar o que não suportava sem arrancar o erro de seu contexto. O Unsupported Attributes Group podia devolver membros incompatíveis dentro de uma coleção. Achatar tudo em um erro superior destruiria o escopo necessário para saber qual ocorrência falhou.

Na codificação, begin-collection, member-name e end-collection delimitavam a estrutura. O desenho considerava analisadores IPP antigos para reduzir o risco de tratarem um nome interno como atributo superior comum. Compatibilidade não lhes dava nova compreensão; impedia que desconhecimento virasse interpretação indevida.

Os exemplos media-col e job-sheet-col eram ilustrações de como definir membros, descoberta e aninhamento. Não constituíam, por si, atributos normativos implantados. Outro documento ainda precisaria fazer a definição concreta.

O RFC 3380 tratava da alteração atômica de atributos de trabalho. O RFC 3381 explicava contadores cujo sentido variava com a alceação. O RFC 3382 cuidava de outra fronteira: transportar vários valores tipados como unidade sem tornar a ordem física parte do significado.

A extensão atualizou RFC 2910 e RFC 2911. RFC 2565 e RFC 2566 continham a base IPP/1.0; RFC 2567 e RFC 2568 registravam requisitos e projeto. RFC 8010 e RFC 8011 consolidaram depois codificação e modelo. Essa cronologia não comprova adoção, comportamento de produto ou impressão concluída.

A distinção permanece importante porque interfaces e programas facilmente dão autoridade a uma posição estável. Uma lista funciona até um serializador ordenar os campos, um membro opcional entrar no meio ou um intermediário reconstruir a coleção. Se a simples permutação muda o resultado, o consumidor depende de uma promessa que o protocolo recusou.

A lente de especificação inicial mínima de Lu Heng explica a contenção: padronizar o menor recipiente reutilizável e os deveres de futuras definições, sem decidir todas elas antecipadamente. Sua lente de camadas da realidade separa ordem codificada, identidade, suporte, aceitação e resultado físico.

O legado do RFC 3382 foi permitir que a representação se movesse sem romper a relação. A coleção guardava membros juntos; nomes únicos e fronteiras explícitas guardavam sua inteligibilidade. A ordem podia continuar sendo apenas um detalhe de uma codificação.

Fontes