|
Diretrizes
para a implementação de Nomes de Domínio Internacionalizados 22 de fevereiro de 2006 |
||
O método de implementação definido na versão 2.0 das Diretrizes para Implementação de IDNs (“Diretrizes para IDNs”) teve o apoio da Diretoria da ICANN em <8 de novembro de 2005>. O endosso refere-se a um período temporário de nove meses, ao final do qual a Diretoria da ICANN deverá receber recomendações específicas de melhorias. O plano de trabalho inicial desse empreendimento já foi anunciado e posteriormente se anunciarão outros marcos e prazos. O processo de revisão das Diretrizes para IDNs foi o seguinte. O workshop sobre IDNs (registro em tempo real aqui) em Luxemburgo ofereceu a base para essa primeira revisão das Diretrizes para IDNs. Depois desse workshop, formou-se um grupo de trabalho constituído de registros de gTLDs e ccTLDs com experiência com IDNs (membros relacionados abaixo) para elaborar uma revisão das diretrizes e apresentá-la para comentários do público. O grupo de trabalho integrou ao seu trabalho os resultados do workshop sobre IDNs em Luxemburgo e publicou um esboço da Versão 2 das Diretrizes para IDNs em 20 de setembro de 2005. Um fórum para comentários do público, aberto até 23 de outubro de 2005, recebeu uma grande variedade de observações e sugestões sobre o esboço inicial da versão 2. Com base nesse material, o grupo preparou e apresentou à Diretoria da ICANN uma versão final 2 das Diretrizes, e solicitou o seu endosso. A Diretoria endossou a versão final 2.0 sem alterações no conteúdo. As Diretrizes para IDNs, versão 2.0, foram preparadas pelos seguintes membros do grupo de trabalho:
O grupo de trabalho agradece às pessoas que contribuíram com o fórum público e àquelas que ofereceram sua assistência como especialistas. Introdução A versão inicial 1.0 das Diretrizes para a Implementação de Nomes de Domínio Internacionalizados foi publicada em 20 de junho de 2003, coincidindo com o início do desenvolvimento dos IDNs em conformidade com o Padrão Proposto pela IETF para Nomes de Domínios Internacionalizados em Aplicativos, conforme descrevem as RFCs 3454, 3490, 3491 e 3492. O método de implementação definido na Versão 1.0 das Diretrizes teve o apoio da Diretoria da ICANN em 27 de março de 2003. Aquele documento especificava as condições em que um registro de DPN que solicitasse a autorização da ICANN para aceitar registros de IDNs poderia começar a fazê-lo. Outro propósito das Diretrizes foi servir como documento de apoio para outros registros estabelecerem suas políticas para IDNs. Em seguida, a experiência adquirida com a prática real de registro serviria como base para a revisão das Diretrizes quando isso fosse necessário. Ao longo da análise que precedeu a presente revisão, e conforme indicam os comentários recebidos sobre o esboço resultante, verificou-se que a versão inicial das Diretrizes exigia extensas modificações. As mudanças exigidas não puderam ser feitas imediatamente por simples acréscimos ao texto inicial. Entretanto, tendo em vista o caráter urgente de algumas preocupações com IDNs e a conseqüente necessidade de respostas rápidas, o grupo de trabalho encarregado da tarefa decidiu produzir o mais rapidamente possível uma versão revisada das Diretrizes, mantendo seu formato original, e depois elaborar um instrumento alternativo para substituir todas juntas. O texto apresentado abaixo não aborda todas as preocupações que atualmente envolvem os IDNs. (Extraímos uma lista desses problemas com base nos comentários do público sobre o texto preliminar, e iremos publicá-la separadamente.) A próxima medida editorial planejada é reformular as Diretrizes de modo que futuramente possam ser adaptadas como um documento de Melhores Práticas Correntes (BCP), para o qual também se solicitará a aprovação formal da IETF. As Diretrizes apresentadas abaixo não estão diretamente relacionadas à conformidade com os padrões para IDNs igualmente mencionados abaixo. O termo “irá/irão” não deve ser interpretado como um instrumento normativo formal. Embora as Diretrizes se apliquem diretamente aos registros de gTLDs, o seu propósito é poderem ser implementadas em outros registros no segundo nível e em outros níveis inferiores. Qualquer resquício de falta de clareza que possa ser inerente à atual redação será eliminado no próximo BCP. Diretrizes 1. Domínios de primeiro nível que implementarem recursos para nomes de domínio internacionalizados o farão em rigoroso cumprimento das exigências técnicas descritas nas RFCs 3454, 3490, 3491 e 3492 (coletivamente, os “padrões para IDNs"). 2. Ao implementarem os padrões para IDNs, os registros de domínios de primeiro nível empregarão um método “baseado na inclusão” (o que significa que pontos de códigos que não são expressamente permitidos pelo registro são proibidos) para identificar conjuntos permissíveis de pontos de códigos entre todo o repertório Unicode, conforme descrição abaixo. 3. (a) Ao implementarem os padrões para IDNs, os registros de domínios de primeiro nível irão associar cada rótulo em um nome de domínio internacionalizado registrado, tal como aparece em seu registro, a uma única escrita. O objetivo dessa restrição é limitar o conjunto de caracteres permitidos dentro de um rótulo. Se for necessária uma especificidade maior, a associação poderá ser feita pela combinação de descritores para idioma e escrita. Outra alternativa é associar um rótulo a um grupo de idiomas, ou a mais de um designador conforme as condições descritas abaixo. (b) Os registros publicarão todo o conjunto de pontos de código que eles oferecem, em tabelas claramente identificadas de caracteres específicos dos IDNs, e definirão variantes de caracteres equivalentes se as políticas para registro assim o exigirem. Todas essas tabelas serão designadas de maneira a indicar a(s) escrita(s) e/ou o(s) idioma(s) coberto(s). (c) Todos os pontos de código em um único rótulo serão provenientes da mesma escrita, conforme define o Anexo 24 dos Padrões Unicode: Nomes de escritas em http://www.unicode.org/reports/tr24. Exceções a essa norma são permissíveis para idiomas com ortografias e convenções já estabelecidas que exigem o uso concomitante de várias escritas. Nesses casos, não se permitirá a co-existência de caracteres visualmente semelhantes de escritas diferentes num mesmo conjunto de pontos de códigos permitidos, a menos que se defina claramente uma política correspondente e uma tabela de caracteres. (d) Todas as políticas para registro baseadas nessas considerações serão documentadas e colocadas à disposição do público, incluindo uma tabela de caracteres para cada conjunto permitido de pontos de códigos, antes que se aceite o registro de qualquer IDN associado a esse tipo de conjunto. 4. Os pontos de códigos permissíveis não incluirão: (a) caracteres para desenho de símbolos a traço (como os do bloco de desenho Unicode Box), (b) símbolos e ícones que não são caracteres alfanuméricos nem ideográficos, como dingbats tipográficos e pictográficos, (c) caracteres com funções bem definidas como elementos de protocolo, (d) marcas de pontuação usadas unicamente para indicar a estrutura de sentenças, (e) marcas de pontuação usadas dentro de palavras só poderão ser permitidas se nenhum ponto anterior as excluir, se forem essenciais para o idioma do registro de IDN e se estiverem associados a normas explícitas sobre o contexto em que podem ser usadas. (f) Nas condições correspondentes, um caractere simples especificado pode ser usado como separador dentro de um rótulo, seja permitindo que o hífen-menos apareça junto com escritas não-latinas, seja designando uma marca de pontuação com função equivalente pertencente àquela escrita. Quando um nome registrado pré-existente exigir que um registro faça uma exceção temporária a uma dessas regras, as condições dessa ação estarão prontamente disponíveis on-line. Nem mesmo em casos excepcionais os registros podem permitir pontos de códigos proibidos pelos padrões para IDNs. 5. Os registros definirão registros de IDNs tanto nas suas representações Unicode quanto na codificação ASCII. No momento, a disponibilidade de uma determinada seqüência Unicode é definida por sua capacidade de codificação no esquema definido na RFC 3491, e mudanças nesse componente dos padrões para IDNs podem ter conseqüências danosas para a operabilidade de um nome Unicode. Como o aparecimento de hífens na terceira e quarta posição de um rótulo indica um esquema de codificação, o registro de qualquer rótulo que contenha hífens nessas posições não será permitido, a menos que os hífens venham depois de um designador de duas letras para um esquema sancionado e o rótulo esteja em conformidade com as especificações correspondentes. 6. Os registros de domínios de primeiro nível trabalharão em conjunto com os respectivos interessados para elaborar políticas de registro específicas para IDNs, com o objetivo de definir métodos coerentes para a implementação de IDNs em benefício dos usuários do DNS de todo o mundo. Os registros de domínios de primeiro nível trabalharão em conjunto entre si para tratar problemas comuns, por exemplo, formando ou nomeando um consórcio para coordenar o contato com comunidades externas, obter a assistência de grupos de apoio, e criar fóruns globais. 7. Os domínios de primeiro nível definirão o que constitui um registro de IDN e quais são as normas de registro correspondentes disponíveis ao Registro IANA para tabelas de IDNs. Se a IANA não publicar o material fundamental para o entendimento das políticas para IDNs de um registro, esse registro deverá colocá-las imediatamente à disposição na Internet, garantindo também que seus registradores chamem a atenção dos possíveis detentores de nomes com IDNs para esse material. 8. Os registros de domínios de primeiro nível devem oferecer recursos com informações sobre as fontes e referências usadas na formação das respectivas políticas para IDNs de todos os idiomas e escritas nas quais oferecem registros de IDNs. 9. O flag UseSTD3ASCIIRules descrito na RFC 3490 deve ser definido quando se fizerem conversões para ASCII a fim de produzir nomes ACE. Observações adicionais O relatório técnico n. 36 do Unicode sobre “Condições de Segurança Unicode”, em http://www.unicode.org/reports/tr36/, e o relatório técnico Unicode preliminar n. 39, em http://www.unicode.org/reports/tr39/, discutem em detalhes o uso enganoso de caracteres visualmente semelhantes de escritas diferentes. O relatório técnico Unicode n. 36 sugere limitações ao repertório de caracteres disponíveis para IDNs nas tabelas apresentadas sob o título “Data files”. A atual restrição dos rótulos de primeiro nível ao alfabeto latino básico com 26 letras faz com que seja necessário definir os atributos do idioma de um IDN sem levar em conta o rótulo de primeiro nível. A discussão em andamento sobre permitir um repertório mais amplo de caracteres em rótulos de primeiro nível pode mudar essa situação, e também mostrar a necessidade de diretrizes específicas para a nova condição.
|
|||
