|
Diretrizes para a implementação de Nomes de Domínio Internacionalizados 20 de setembro de 2005 |
||
A versão preliminar 2.0 dessas diretrizes foi publicada em 19 de setembro de 2005. Ela reflete as experiências dos registros de IDNs na implementação da versão 1.0 das diretrizes. Receberam atenção especial as preocupações manifestadas sobre o uso enganoso de caracteres de escritas diferentes que causam confusão visual em rótulos individuais de IDNs. A elaboração da versão 2.0 seguiu as seguintes etapas: Os seguintes indivíduos prepararam uma revisão preliminar da versão 1.0 das Diretrizes para IDNs:
A versão preliminar inicial 2.0 ficará publicada durante 30 dias para comentários do público e em seguida passará por alterações de acordo com os comentários recebidos ao longo desse período. Em seguida, a Diretoria receberá uma versão final 2.0 para endosso. Os registros de gTLDs devem estabelecer políticas para IDNs em conformidade com essas Diretrizes e implementarão medidas de apoio aos procedimentos descritos abaixo com a devida presteza. Com exceção dos detalhes administrativos que são claramente específicos da operação de DPNs, o objetivo dessas Diretrizes é que sejam aplicadas em outros registros, em todos os níveis. À medida que prossegue o aperfeiçoamento dos IDNs, a ICANN e os registros de IDNs irão analisar essas diretrizes em intervalos regulares e revê-las quando a experiência indicar necessidade de revisão. Versões anteriores Versão 1.0: As Diretrizes da ICANN para a Implementação de Nomes de Domínio Internacionalizados, Versão 1.0, foram publicadas em 20 de junho de 2003, coincidindo com o início do desenvolvimento de IDNs em conformidade com os Parâmetros Propostos pela IETF para Nomes de Domínio Internacionalizados em Aplicativos, segundo estabelecem as RFCs 3454, 3490, 3491 e 3492. O método de implementação definido na Versão 1.0 das Diretrizes teve o endosso da Diretoria da ICANN em 27 de março de 2003. Diretrizes 1. Os registros de 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 (denominadas em conjunto os “parâmetros para IDNs "). 2. Ao implementarem os parâmetros para IDNs, os registros de domínios de primeiro nível aplicarão um método “baseado na inclusão” (o que significa que code pointss que não são expressamente permitidos pelo registro são proibidos) para identificar conjuntos permissíveis de code points entre todo o repertório Unicode, conforme descrição abaixo. 3. (a) Ao implementarem os parâmetros para IDNs, os registros de domínios de primeiro nível associarão cada rótulo num nome de domínio internacionalizado (conforme aparece em seu registro) a um único idioma ou uma única escrita, usando os designadores aceitos para ambos. Em qualquer caso, a restrição destina-se a limitar o conjunto de caracteres permitidos num rótulo. Caso se queira uma especificidade maior, a associação poderá ser feita ao combinar um designador de um idioma com um designador de escrita. Como alternativa, é possível associar um rótulo a um grupo de idiomas, ou a mais de um designador nas condições descritas a seguir. A RFC 3066 ilustra os designadores de idiomas (http://www.rfc-editor.org/rfc/rfc3066.txt). Os designadores de escrita estão ilustrados na ISO 15924 e no Relatório Técnico Unicode #23 (http://www.unicode.org/reports/tr23/). (b) Os registros publicarão o conjunto completo de code points que colocarem à disposição e tabelas de caracteres específicas para IDNs e claramente identificadas, e deverão definir variantes de caracteres equivalentes se as normas de registro se basearem nesses caracteres. Toda tabela desse tipo deve ser designada de uma maneira que indique o(s) idioma(s) e/ou escrita(s) aos quais se refere. (c) Todos os code points num único rótulo devem ser provenientes da mesma escrita, conforme determinam as propriedades de caracteres Unicode (UTF#23). Permitem-se exceções a essa regra no caso de idiomas com ortografia e convenções definidas que exigem o uso misto de várias escritas. Caracteres de escritas diferentes que podem causar confusão visual não deverão aparecer no mesmo rótulo, a menos que haja motivos lingüísticos legítimos muito importantes para fazê-lo. Cada situação deve ser associada a um idioma específico, com uma tabela de caracteres correspondente disponível antes que se aceitem registros desses nomes. (d) Todas as políticas para registro baseadas nessas considerações deverão ser documentadas e colocadas à disposição do 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 esses conjuntos. 4. Os code points permissíveis não incluirão: (a) caracteres com desenhos de símbolos (como os do bloco de desenho Unicode), (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 de pontuação sem significado gramatical no idioma ao qual está associado o registro de IDNs (com a pontuação necessária, incluindo caracteres como o ESPAÇO PARA PALAVRAS ETÍOPE em amárico e o PONTO INTERMEDIÁRIO em catalão), e (d) outros caracteres com funções bem definidas como elementos de protocolos. Quando um registro decidir que uma exceção a qualquer uma dessas normas é apropriada, conforme se discute na Diretriz 3, o registro deverá documentar a base dessa decisão no Registro IANA para Tabelas de IDNs ou colocá-la imediatamente à disposição do público na Internet. Nem mesmo no caso de exceções os registros poderão permitir code points proibidos pelos padrões para IDNs. 5. Os registros precisam definir o escopo de um registro de IDNs para representações, tanto em Unicode quanto no código ASCII. No momento, a disponibilidade de uma determinada seqüência Unicode é determinada por sua capacidade de ser codificada para o esquema definido na RFC 3491, e mudanças nesse componente do padrão para IDNs podem ter conseqüências desastrosas para a operabilidade de um nome Unicode. Por esse motivo, um registro de IDNs deve tratar a forma codificada em ASCII como o nome registrado primário, e incluir em sua documentação uma descrição dos fatores que determinam a forma em que essa seqüência aparece na interface do usuário. 6. Os registros de domínios de primeiro nível irão colaborar com os participantes e interessados para elaborar políticas de registro específicas para IDNs, com o objetivo de definir métodos consistentes de implementação de IDNs para beneficiar os usuários do DNS em todo o mundo. Os registros de domínios de primeiro nível irão colaborar entre si para tratar problemas comuns, por exemplo, ao formarem ou indicarem um Consórcio para coordenar o contato com comunidades externas, solicitar a assistência de grupos de apoio e criar foros globais. 7. Os registros (e registradores) de domínios de primeiro nível precisam definir o que constitui um registro de IDN e quais são as normas de registro correspondentes disponíveis no <Registro IANA para tabelas de IDNs>. Se a IANA não publicar materiais fundamentais para o entendimento das políticas para IDNs de um registro, este deverá apresentá-las prontamente on-line, de algum outro modo. 8. Os registros de domínios de primeiro nível devem fornecer as informações sobre as fontes e referências usadas na formação das políticas correspondentes para registro de IDNs em todos os idiomas e escritas para os quais oferecem registro de IDNs. Detalhes administrativos Para registros que possuem contratos com a ICANN: Registros com contratos de patrocínio ou contratos de registro com a ICANN também precisam seguir as exigências de formato para Nomes Registros em seus contratos de patrocínio ou de registro. De um modo ou de outro, os contratos determinam que todos os Nomes Registrados (incluindo os nomes ACE) precisam seguir a sintaxe abaixo no formato ampliado Backus-Naur (BNF), conforme descreve a RFC 2234: ponto = %x2E ; "." Além disso, devem-se observar os limites de comprimento. Para cumprir esses requisitos, recomendamos que se use o flag UseSTD3ASCIIRules descrito na RFC 3490 ao realizar conversões ToASCII para produzir nomes ACE, e a restrição de formato resultante deve ser interpretada conforme o resumo acima. Para gTLDs não-patrocinados: As normas baseadas nessas Diretrizes não devem interferir com o acesso equivalente a Serviços de Registro do Operador do Registro por todos os registradores credenciados pela ICANN que possuem Contratos entre Registro e Registrador em vigor. De modo geral, os operadores de registro de DPNs não-patrocinados concederão um prazo de 30 dias para notificar a ICANN e os registradores autorizados sobre a criação ou revisão das normas. Em situações urgentes, o operador de registro e a ICANN podem convencionar por escrito um prazo menor. Também será possível anexar condições especiais quando se publicarem informações específicas para um determinado momento, por exemplo, situações em que se prevê uma “corrida” pelos domínios. Observações adicionais O uso enganoso de caracteres de escritas diferentes que causam confusão visual é discutido em detalhes no Relatório Técnico Unicode #36 sobre “Considerações de Segurança Unicode” (Unicode Security Considerations), em http://www.unicode.org/reports/tr36/. As tabelas apresentadas na seção “Arquivos de dados” (Data files) sugerem limitações ao repertório de caracteres disponível para IDNs. No momento, está em curso uma revisão da lista de idiomas na ISO 639-2, ao longo dos preparativos para a ISO 639-3, cujo esboço já está bastante avançado (na data de publicação dessas Diretrizes). A referência à norma BCP47 mencionada nas condições para a Tabela de Idiomas da IANA para IDNs deverá ser modificada quando se concluir a ISO 639-3, e destacamos também que no momento a IETF está elaborando a versão final de um documento para substituir essa BCP. Isso irá oferecer novos meios para especificar idiomas, incluindo designações para autoridade ortográfica como componentes do tag de um idioma. O grupo que está preparando essa revisão é o Grupo de Trabalho da IETF para Atualização de Tags de Idiomas para Registros (ltru). Quando o seu trabalho se converter em normas formais, os resultados poderão exigir outras modificações nas Diretrizes para IDNs. O agrupamento de idiomas com base em seu uso de uma única escrita (como os idiomas com escrita latina, africana ou européia) pode facilitar a elaboração de políticas para IDNs nos aspectos técnicos, reduzindo assim o potencial de confusão. A menos que haja necessidade de associar rótulos individuais em um IDN a escritas diferentes, mesmo quando se aplicarem outras políticas para escritas, a maneira menos confusa de designar um IDN em geral será a associação com um único idioma. Entretanto, a atual restrição de rótulos de primeiro nível ao alfabeto latino básico de 26 letras freqüentemente exigirá que os atributos do idioma de um IDN sejam determinados sem levar em conta o rótulo de primeiro nível. A discussão em curso quanto a permitir um repertório mais vasto de caracteres em rótulos de primeiro nível pode mudar essa situação, e também criar a necessidade de outras diretrizes específicas para a nova situação.
|
|||
