Resumo

  • RFC 1766 deixava os segmentos visíveis, mas orientava as aplicações a tratar a etiqueta completa como um único token; as subetiquetas organizavam o registro, não formavam um menu.
  • Códigos ISO, registros da IANA e o espaço de uso privado ocupavam partes distintas da sintaxe. A especificação que empregasse a etiqueta definiria sua relação com o objeto informativo.
  • Revisões posteriores acrescentaram operações explícitas de correspondência. Elas não transformaram cada hífen da gramática de 1995 em um caminho de navegação.

O hífen parecia uma trilha

Em março de 1995, a RFC 1766 apresentou uma forma compacta de indicar o idioma usado em um objeto informativo. A aparência podia sugerir uma árvore: uma etiqueta principal, seguida de partes opcionais separadas por hífens. en-US era familiar; az-arabic e az-cyrillic começavam do mesmo jeito. O documento traçou um limite para essa leitura: as aplicações deveriam tratar a etiqueta inteira como um único token. A divisão entre etiqueta principal e subetiquetas era um mecanismo administrativo, não um recurso de navegação.

Essa instrução importa porque uma sequência legível não é uma hierarquia de comandos. A etiqueta principal podia ter de uma a oito letras, e cada subetiqueta obedecia ao mesmo limite. Não se permitia espaço dentro da etiqueta. Maiúsculas e minúsculas não mudavam o valor. Havia convenções para escrever códigos de países em caixa alta e códigos de idioma em caixa baixa, mas a RFC 1766 dizia que a capitalização não carregava significado próprio.

O espaço de nomes tinha limites definidos. Etiquetas principais de duas letras seguiam a ISO 639. i ficava reservado a registros definidos pela IANA; x abria o uso privado, cujas subetiquetas não seriam registradas pela IANA. Outros valores principais dependeriam de uma revisão da norma. Na primeira subetiqueta, códigos de duas letras seguiam a ISO 3166 alpha-2; valores de três a oito letras podiam ser registrados na IANA. Subetiquetas posteriores também podiam ser registradas.

Essa estrutura fazia duas coisas que podem ser confundidas: permitia ler a sequência em partes e dava aos administradores uma forma de organizar o espaço de nomes. Ela não mandava percorrer essas partes como diretórios, nem atribuía a cada segmento o mesmo sentido em todas as aplicações. A norma que definisse o contexto de uso determinaria a relação entre etiqueta e objeto informativo.

O registro dava publicidade aos valores

Os exemplos da RFC 1766 abrangiam identificação de país (en-US), dialeto ou variante (no-nynorsk, en-cockney), uma língua registrada pela IANA (i-cherokee) e variações de escrita (az-arabic, az-cyrillic). O texto trazia uma ressalva importante: nenhuma das subetiquetas citadas tinha sido de fato atribuída. Os exemplos mostravam a sintaxe; não eram uma lista de valores disponíveis.

Para propor um valor fora das atribuições ISO predefinidas, a pessoa solicitante preenchia um formulário com o nome da língua, seu nome nativo, uma descrição publicada e outros dados. O pedido passava por duas semanas de revisão em uma lista aberta. Um revisor designado pelo diretor da área de Aplicações do IETF podia encaminhá-lo à IANA ou rejeitá-lo diante de objeções relevantes; a decisão podia ser contestada perante o IESG. Uma grafia se tornava referência pública verificável por meio de um registro, e não apenas porque alguém acrescentara outro sufixo depois do hífen.

O mecanismo era limitado por desenho: registrava identificadores e referências, não uma interface universal. A etiqueta, por si só, não dizia a cada protocolo se deveria escolher uma representação, filtrar uma biblioteca, abrir uma rota ou exibir um seletor de idioma. Esse comportamento pertencia ao contexto em que a etiqueta era usada.

Um cabeçalho podia listar idiomas sem definir o seletor

A RFC 1766 também definiu Content-Language, que podia listar várias etiquetas completas. Para multipart/alternative do MIME, acrescentou o parâmetro Differences, permitindo indicar que as partes alternativas diferiam pelo idioma do conteúdo. O documento explicou por que um leitor poderia usar essa informação, mas deixou fora de seu escopo o mecanismo que escolheria qual parte apresentar.

Três perguntas permaneceram separadas: qual sequência identifica o idioma de um objeto, qual elemento de protocolo a transporta e o que a aplicação receptora faz com ela. A etiqueta podia aparecer em um cabeçalho de conteúdo; um contêiner podia apontar alternativas linguísticas; cada leitor ainda precisaria de seu próprio comportamento de seleção. A RFC fornecia uma marca comum e um lugar para transportá-la, não uma navegação universal.

A evolução posterior evidencia a distinção. Publicada em 2001, a RFC 3066 permitiu dígitos nas subetiquetas e introduziu language-range. Um intervalo podia corresponder à etiqueta completa ou a um prefixo encerrado na fronteira de um hífen. Essa era uma operação de correspondência definida. A RFC 3282 especificou depois os cabeçalhos Content-Language e Accept-Language, com intervalos de preferência e valores de qualidade opcionais. Esses acréscimos criaram regras explícitas em torno das etiquetas, mas não transformaram o hífen original em um caminho genérico.

As RFCs 4646, de 2006, e 5646, de 2009, continuaram a revisão do BCP 47. A sequência mostra que gramática e registro evoluíram. Não demonstra que todo cliente processasse todos os valores corretamente nem que uma etiqueta escolhesse automaticamente uma página, uma tradução ou uma forma de exibição. A lição histórica da RFC 1766 é mais específica: um identificador estruturado pode continuar sendo um valor indivisível para a aplicação, enquanto seus segmentos servem a convenções administrativas.

Fontes e limites

A especificação é a RFC 1766. A sequência de revisões está documentada nas RFC 3066, RFC 3282, RFC 4646 e RFC 5646. Esses textos sustentam a gramática, os registros e as mudanças posteriores de protocolo; não demonstram implementação ou adoção universais.