Resumo

  • O RFC 1590, de março de 1994, ampliou os antigos “tipos MIME” do correio para “tipos de mídia” compartilhados por aplicações. Uma proposta era publicada na lista ietf-types e, duas semanas depois, podia ser enviada à IANA para registro e atribuição de OID.
  • O registro comum podia crescer; cada ambiente continuava a recomendar os formatos adequados a seus usuários. Para o correio, uma lista pequena de tipos amplamente implementados podia constar de uma declaração de aplicabilidade própria.

Uma fila para impedir dez nomes para o mesmo objeto

Uma fotografia chega ao e-mail e a um arquivo digital. Se cada sistema inventar sua etiqueta, o mesmo conjunto de bytes passa a responder por nomes diferentes. O contrário também acontece: duas estruturas distintas acabam dividindo uma etiqueta, e um programa abre o objeto errado com confiança burocrática. A fila de registro existia para tornar esse problema público antes de virar uma convenção difícil de tirar do código.

O RFC 1521 havia estabelecido o mecanismo MIME para descrever corpos de mensagens. No correio assíncrono, o remetente geralmente desconhecia as capacidades do software do destinatário. Um conjunto pequeno de formatos conhecidos aumentava a chance de leitura. Quando as mesmas designações passaram a servir outros usos, limitar o registro a essa prudência postal ficou apertado. Jon Postel, no RFC 1590, chamou as designações de “tipos de mídia” e abriu seu alcance para além da caixa de entrada.

O caminho começava com uma mensagem a ietf-types. O proponente publicava tipo e subtipo; enquanto a entrada era proposta, o subtipo levava a forma x-. A discussão podia corrigir ambiguidades no nome, referências imprecisas a versões ou perfis, escolha de identificadores de objeto e problemas de segurança conhecidos. Também havia espaço para dizer que um formato se destinava a um uso específico. Era uma oportunidade de perguntar antes de carimbar.

Passadas duas semanas, o proponente enviava a solicitação à IANA. O RFC descrevia revisão administrativa, registro, atribuição de um OID na ramificação da IANA e disponibilização pública. O formulário exigia tipo, subtipo, parâmetros necessários e opcionais, considerações de codificação, segurança, especificação e contato. O registro criava uma referência comum para programas que talvez jamais conversassem diretamente sobre suas escolhas de nomes.

Havia casos em que o objeto circulava, mas sua especificação pública completa não existia. RFC 1590 aceitava identificar um pacote de software e sua versão para tornar o fluxo reconhecível. O detalhe importa: “documento de um certo programa, versão tal” é uma pista melhor do que um nome vistoso e vazio. Um programa receptor ainda precisava de código para entender os bytes daquela versão. O cadastro podia apontar a gaveta; não abria o envelope sozinho.

Uma categoria principal inteiramente nova exigia texto em forma de RFC, ou pronto para vir a ser um, e participação no processo de padrões. Acrescentar um subtipo a uma categoria existente seguia a via administrativa mais leve. O RFC também pôs as recomendações para um ambiente específico em outro lugar: uma declaração de aplicabilidade podia dizer quais formatos de correio mereciam adoção ampla. Assim, o catálogo comum podia ter espaço sem obrigar um leitor de e-mail antigo a reproduzir vídeo.

O desenho era uma divisão de tarefas. A IANA mantinha um vocabulário compartilhado, autores de formatos descreviam seus objetos e programas escolhiam o que sabiam processar. A espera de duas semanas parecia pequena diante de sua consequência: oferecer um instante público para melhorar o nome antes que anos de software o transformassem em peça de infraestrutura.