|
Diretrizes
para a implementação de Nomes de Domínio Internacionalizados 8 de novembro de 2005 |
||
Em <8 de novembro de 2005> a Diretoria da ICANN endossou o método de implementação definido na versão 2.0 das Diretrizes para a Implementação de Nomes de Domínio Internacionalizados. O endosso refere-se a um período temporário de nove meses durante o qual a Diretoria da ICANN receberá recomendações específicas para melhoria dos IDNs. A Corporação anunciou um plano de trabalho inicial e posteriormente anunciará outros marcos e prazos importantes. O processo de revisão das diretrizes para IDNs foi apresentado da seguinte maneira: o workshop sobre IDNs (registro em tempo real aqui) forneceu a base para essa primeira revisão das diretrizes. Depois desse workshop, formou-se um grupo de trabalho de registros de gTLDs e ccTLDs com experiência em IDNs (membros relacionados abaixo) para elaborar uma revisão das diretrizes e depois apresentá-las ao público para comentários. O grupo de trabalho incorporou os resultados do workshop sobre IDNs em Luxemburgo ao seu trabalho e publicou uma versão 2.0 preliminar das Diretrizes para IDNs em 20 de setembro de 2005. O 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.0. Com base nesse material, o grupo preparou um esboço final da versão 2.0 das diretrizes e o submeteu à aprovação da Diretoria da ICANN, que o endossou sem alterações no conteúdo. Os seguintes membros do grupo de trabalho prepararam a versão 2.0 das Diretrizes para IDNs:
O grupo de trabalho deseja agradecer publicamente às pessoas que contribuíram com o fórum público e às que ofereceram 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 de IDNs, conforme o “Padrão proposto pela IETF para padronização de nomes de domínio internacionalizados em aplicativos”, conforme estabelecem as RFCs 3454, 3490, 3491 e 3492. Em 27 de março de 2003 a Diretoria da ICANN endossou o método de implementação definido na versão 1.0 das Diretrizes. Esse documento definia as condições para que um registro de DPNs que solicitasse a autorização da ICANN para aceitar registros de IDNs pudesse começar a fazê-lo. Além disso, as Diretrizes serviriam também como documento de apoio para outros registros definirem políticas para IDNs. Em seguida, a experiência obtida na prática real de registro serviria como base para a revisão das Diretrizes sempre que isso se tornasse necessário. Ao longo da análise que precedeu a atual revisão, e conforme indicam os comentários recebidos sobre o esboço resultante, a versão inicial das Diretrizes exigia grandes modificações. As mudanças necessárias não poderiam ser feitas imediatamente apenas acrescentando elementos ao texto inicial. Porém, considerando a urgência de algumas preocupações quanto a IDNs e a necessidade de uma resposta rápida, o grupo de trabalho incumbido da tarefa decidiu produzir o mais rapidamente possível uma versão revisada das Diretrizes mantendo seu formato inicial, e então elaborar um instrumento alternativo para substituir todas elas. O texto apresentado abaixo não trata todas as preocupações que envolvem os IDNs no momento. (Com base nos comentários públicos sobre o texto preliminar, produziu-se uma lista dessas preocupações que será publicada separadamente.) A próxima ação editorial prevista é reformular as diretrizes de forma que futuramente possam ser usadas como documento de Melhores Práticas (BCP), para o que também se solicitará a aprovação formal da IETF. As diretrizes apresentadas abaixo não representam uma imposição dos parâmetros para IDNs mencionados a seguir. O termo “irá/irão” (will, no original) não deve ser interpretado como um instrumento normativo formal. Embora as diretrizes se apliquem diretamente aos registros de gTLDs, elas devem ser adequadas para a implementação em outros registros no segundo nível e em níveis mais baixos. Qualquer falta de clareza residual na redação atual será resolvida no documento de BCP. Diretrizes 1. Registros de domínios de primeiro nível que implementarem recursos para nomes de domínio internacionalizados o farão em obediência estrita às exigências técnicas descritas nas RFCs 3454, 3490, 3491 e 3492 (denominadas em conjunto de “parâmetros para "IDNs"). 2. Ao implementarem os parâmetros para IDNs, os registros de domínios de primeiro nível usarão um método “baseado na inclusão” (o que significa que code points que não são expressamente permitidos pelo registro estão proibidos) para identificar conjuntos de code points permitidos entre todo o repertório Unicode, conforme descrição a seguir. 3. (a) Ao implementar os parâmetros para IDNs, os registros de domínios de primeiro nível associarão cada rótulo em um nome de domínio internacionalizado registrado, conforme 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 houver necessidade de uma especificação maior, a associação pode ser feita ao combinar indicadores para o idioma e para a escrita. Ou então, um rótulo pode ser associado a um conjunto de idiomas, ou a mais de uma designação, conforme as condições descritas abaixo. (b) Os registros publicarão em tabelas de caracteres específicos para IDNs claramente identificados o conjunto total de code points que oferecem, e definirão as variantes de caracteres equivalentes, se as políticas para registro assim o exigirem. Todas essas tabelas indicarão a(s) escrita(s) e/ou idioma(s) a que se referem. (c) Todos os code points em um único rótulo serão provenientes da mesma escrita, conforme determina o Anexo 24 dos Parâmetros Unicode: Nomes de escritas em http://www.unicode.org/reports/tr24. São exceções os idiomas com ortografias e convenções já estabelecidas que exigem o uso misto de várias escritas. Nesses casos, caracteres de diferentes escritas que podem causar confusão visual não poderão coexistir em um único conjunto de code points permitidos, a menos que se definam 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 estarão disponíveis ao público, incluindo uma tabela de caracteres para cada conjunto permitido de code points, antes que se aceite o registro de qualquer IDN associado a esse conjunto. 4. Os code points permitidos não incluirão: (a) caracteres para desenho de símbolos (como os do bloco Unicode para desenho – Drawing), (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 protocolos, (d) marcas de pontuação usadas apenas para indicar a estrutura de sentenças, (e) marcas de pontuação que são usadas no meio de palavras só serão permitidas se não forem excluídas por algum dos pontos precedentes, se forem essenciais ao idioma do registro do IDN, e se estiverem associadas a normas indicativas expressas sobre o contexto no qual pode ser usadas, (f) nas condições correspondentes, um único caractere específico pode ser usado como separador dentro de um rótulo, seja permitindo que o hífen – menos apareça com escritas não-latinas, seja designando uma marca de pontuação com a mesma função naquela escrita. Quando um nome registrado pré-existente exigir que um registro faça uma exceção temporária a qualquer uma dessas normas, as condições dessa ação deverão estar prontamente disponíveis on-line. Nem mesmo em caso de exceção um registro poderá permitir code points proibidos pelos parâmetros para IDNs. 5. As empresas de registro definirão um registro de IDN em sua representação Unicode e em código ASCII. No momento, a disponibilidade de uma determinada seqüência Unicode é determinada pela sua capacidade de codificação no esquema definido na RFC 3491, e mudanças nesse componente dos parâmetros para IDNs podem interferir na operabilidade de um nome Unicode. Como a ocorrência de hífens na terceira e quarta posição de um rótulo indica um esquema codificado, não se pode permitir o registro de qualquer rótulo com hífens nessas posições, a menos que os hífens venham depois de um designador de duas letras para um esquema aprovado e o rótulo esteja de acordo com as especificações correspondentes. 6. Os domínios de primeiro nível trabalharão em conjunto com os envolvidos para elaborar políticas específicas para registro de IDNs, com o objetivo de definir regras coerentes de implementação de IDNs em benefício dos usuários do DNS em todo o mundo. Os registros de domínios de primeiro nível também trabalharão em conjunto para tratar problemas comuns, por exemplo formando ou indicando um consórcio que coordene o contato com comunidades externas, viabilize a assistência de grupos de apoio e crie fóruns globais. 7. Os domínios de primeiro nível definirão o que é um registro de IDN e quais são as normas de registro correspondentes disponíveis ao registro da IANA para tabelas de IDNs. Se a IANA não publicar material fundamental para compreender as políticas para IDNs de um determinado registro, esse registro fornecerá esse material on-line, e garantirá que seus registradores chamem a atenção dos possíveis detentores de nomes com IDNs para o fato. 8. Os registros de domínios de primeiro nível devem fornecer informações sobre as fontes e referências usadas na formação das respectivas políticas para registro de IDNs para todos os idiomas e escritas em que oferecem registro de IDNs. Observações adicionais O uso enganoso de caracteres de diferentes escritas que podem causar confusão visual está descrito em detalhes no Relatório Técnico Unicode número 36 sobre “Condições de segurança para Unicode” em http://www.unicode.org/reports/tr36/ e no Relatório Técnico Unicode preliminar número 39, em http://www.unicode.org/reports/tr39/. Nas tabelas sob o título “Data files”, o relatório número 36 sugere limitações ao repertório de caracteres disponíveis para IDNs. A atual restrição de rótulos de primeiro nível ao alfabeto latino básico com 26 letras faz com que seja necessário determinar 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 conjunto mais amplo de caracteres nos rótulos de primeiro nível pode mudar isso, e também indicar a necessidade de diretrizes específicas para a nova condição.
|
|||
