Relatório de status do Grupo de Trabalho Interno para Nomes de Domínio Internacionalizados, do Conselho Administrativo da ICANN CONTEÚDO I. ATIVIDADES DO GRUPO DE TRABALHO PARA IDN ATÉ O MOMENTO A. Formação C. Pesquisas D. Consultas II. RESUMO DAS RESPOSTAS ÀS PESQUISAS Pesquisa B: Questões políticas III. PRÓXIMAS ETAPAS B. Grupos de Trabalho para IDNs ANEXOS Pesquisa B: Questões políticas I. Atividades do Grupo de Trabalho para IDNs até o momento O Conselho Administrativo da ICANN criou o Grupo de Trabalho para IDNs aprovando a resolução 1.39 durante a reunião do Conselho Administrativo em Melbourne, Austrália, em 13 de março de 2001. A resolução afirma: “Com o propósito de promover o melhor entendimento das questões técnicas e políticas que envolvem a internacionalização de nomes de domínio, o Conselho Administrativo designa um grupo de trabalho interno ... para identificar os diversos esforços de internacionalização e os assuntos associados, para participar do diálogo com especialistas técnicos e outros participantes desses esforços, e para fazer as recomendações apropriadas ao Conselho Administrativo.” O Conselho indicou Masanobu Katoh como presidente do Grupo de Trabalho, e Karl Auerbach, Ivan Moura Campos, e Vinton Cerf como membros. Em abril de 2001. o Grupo de Trabalho para IDN publicou a definição de sua tarefa no site da ICANN. A definição da tarefa declara que o Grupo de Trabalho iria se engajar no levantamento de fatos referentes a três categorias de perguntas: 1. Quais são os problemas técnicos levantados pelos IDNs, quais as possíveis soluções, e quais os prós e contras relativos a estas possíveis soluções? 2. Quais são as questões jurídicas e outras questões políticas levantadas pelos IDNs, e quais as possíveis soluções? 3. Quais atividades de IDNs estão em andamento, qual é a sua extensão, e qual a sua relação com as questões técnicas e jurídicas mencionadas acima? A definição da tarefa deixa claro que o Grupo de Trabalho “considera sua missão limitada ao levantamento de fatos para informação do Conselho e da comunidade da ICANN, de modo que ICANN possa cumprir sua missão de gerenciamento técnico dos nomes de domínio na Internet e dos números IP. O grupo de trabalho não irá estabelecer padrões técnicos para IDNs”. O Grupo de Trabalho preparou três pesquisas desenvolvidas para obter respostas para as três categorias de perguntas citadas acima. Estas pesquisas foram publicadas no site da ICANN em 30 de abril de 2001 (http://www.icann.org.br/committees/idn/survey-30apr01.htm), com uma data de retorno de 10 de maio de 2001. Além disso, as pesquisas foram enviadas por e-mail para numerosas entidades e indivíduos envolvidos com IDNs. Até 20 de maio de 2001, o Grupo de Trabalho havia recebido 14 respostas. Os membros do Grupo de Trabalho também se encontraram com entidades envolvidas com IDNs para obterem mais informações. O Sr. Katoh participou da reunião do Consórcio de Nomes Multilíngües na Internet (Multilingual Internet Names Consortium - MINC), em Melbourne, em 14 de março de 2001. O MINC está realizando a sua própria pesquisa sobre atividades IDN, e o Grupo de Trabalho aguarda o resultado dessa pesquisa. O Sr. Katoh participou da reunião dos fundadores do Consórcio de Nomes Árabes na Internet (Arabic Internet Names Consortium - AINC) em Amã, na Jordânia, em 1 de abril de 2001. II. Resumo das respostas à pesquisa Em anexo estão as respostas à pesquisa, recebidas até 20 de maio de 2001. Conforme discussão abaixo, na Seção III, o Grupo de Trabalho gostaria de receber outras respostas à pesquisa, bem como reações às respostas anexadas. A seguir, um breve resumo das respostas. Quais outras tecnologias atualmente permitem o uso de caracteres não-latinos como nomes de domínio? Diferentes pessoas identificaram entre duas e quatro abordagens básicas. Em termos muito simplificados para leigos, o sistema de nomes de domínio originalmente foi desenvolvido para usar caracteres latinos em formato ASCII. Isso parecia adequado no momento, tendo em vista o início do desenvolvimento da Internet e do DNS nos Estados Unidos e na Europa Ocidental. Existem duas abordagens básicas para os IDNS. Uma é enviar nomes de domínio pela Internet em códigos locais, tais como GB, BIG5, SJIS, ou em um Unicode Transformation Format (Formato de Transformação Unicode) como UTF-8. Essa abordagem eventualmente pode exigir a reconfiguração de servidores na Internet a fim de conservar a interoperabilidade total. De fato, algumas pessoas sugeriram que todo o DNS deve ser reestruturado para acomodar estas diversas escritas. Por essa razão, essa abordagem pode ser chamada como a abordagem de IDNs “do ponto de vista do servidor” . A segunda abordagem é traduzir o código local ou o Unicode para o ASCII Compatible Encoding (ACE – Código Compatível com ASCII) no computador do usuário. Uma variante dessa abordagem é o “Row-based ASCII Compatible Encoding” (RACE). O nome de domínio passa pela Internet para ASCII. A abordagem da tradução exige usuários interessados em usar IDNs para adquirir o software correspondente, a fim de efetuar a tradução para ASCII. Por esta razão, esta abordagem pode ser chamada de abordagem de IDNs “do ponto de vista do cliente”. Muitos sugeriram uma variedade de implementações específicas destas duas abordagens básicas. Além disso, alguns propuseram abordagens híbridas, que exigem mudanças tanto para o cliente quanto para o servidor. 2. Quais são os pontos fortes e fracos das tecnologias mencionadas na pergunta 1? Por favor, dê exemplos concretos. A principal vantagem do ponto de vista do servidor é que ela não exige nenhuma implementação pelo cliente; os usuários que provavelmente usariam IDNs já possuem códigos locais instalados em seus computadores. As desvantagens incluem: o tempo significativo que pode ser necessário para implementar ferramentas especiais nos servidores da Internet em todo o mundo; o possível desenvolvimento de raízes alternativas, uma vez que se tenham feito mudanças fundamentais no DNS; e equivalência de nomes. O mesmo valor codificado poderia representar diferentes conjuntos caracteres, o que causaria problemas de segurança. A principal vantagem da abordagem do lado do cliente é que não exige nenhuma implementação pelo servidor, o que teoricamente permitiria que fosse implementada mais depressa. As desvantagens incluem: usuários que precisariam instalar softwares de conversão; dificuldades em converter conjuntos de caracteres locais como JIS, em Unicode, que então teria de ser convertido em ASCII; limitações no comprimento de nomes de domínio (ver resposta à pergunta 9 da pesquisa A) e questões de propriedade intelectual (ver resposta à pergunta 11 da pesquisa A). 3. Existem mais problemas relativos a escritas específicas? Por que? De acordo com algumas respostas, para algumas escritas existe mais de um esquema de codificação. Além disso, alguns idiomas possuem mais de uma escrita – chinês tradicional e simplificado, por exemplo. O idioma chinês também possui um número muito grande de caracteres. No árabe, os espaços nas frases alteram o significado e o formato de um caractere, e em hebraico determinados caracteres podem ser omitidos. Estas características representam dificuldades para as duas abordagens discutidas acima. 4. Visto que existem pontos fracos nas tecnologias, quais grupos estão trabalhando para desenvolver soluções? A Força-Tarefa para Engenharia da Internet (IETF) possui um Grupo de Trabalho para Nomes de Domínio Internacionalizados (IDNWG), que está trabalhando com afinco neste assunto. Outros grupos incluem o Consórcio Unicode, o MINC e o Consórcio para Nomes de Domínio Chineses (CDNC). Alguns dos que responderam sugeriram que as questões específicas relativas a determinadas escritas (ver resposta à pergunta 3) devem ser resolvidas em nível local ou regional. 5. Quais são as diferentes soluções sendo consideradas? Quais as mais promissoras? Quanto tempo ainda será necessário para desenvolver uma solução que funcione? Muitos responderam, afirmando que a IEFT parece estar voltada para os Nomes de Domínio Internacionalizados em Aplicação (IDNA), o que envolve uma abordagem do ponto de vista do cliente. Walid anunciou que possui uma patente, que segundo ele, lhe confere direitos sobre aspectos dos IDNA. Colocando de lado a questão de patentes, alguns respondentes afirmam que a IETF ainda precisará de pelo menos seis meses para concluir o seu trabalho. Várias abordagens do ponto de vista do servidor estão sendo promovidas. Algumas exigirão uma ampla reestruturação do DNS e levarão mais de uma década para serem totalmente implementadas. Neteka está promovendo uma abordagem híbrida, tanto do lado do cliente quanto do servidor. 6. No momento, não existem padrões aceitos para os IDNs. Isso acontece porque existem tecnologias competindo entre si, ou porque o problema subjacente é que ainda não existe a “melhor” solução? Muitos dos que responderam observaram que o problema dos IDNs é extremamente complexo, e que não há uma solução ideal. Além disso, existem diferentes interessados, e abordagens diferentes possuem vantagens diferentes, de diferentes pontos de vista. Neteka identificou os seguintes “grupos” de interessados: administradores/operadores de sistemas; usuários finais; e técnicos. A Register.com observou que “em razão do caráter essencial do DNS para a comunidade da Internet, é importante desenvolver um profundo entendimento dos prós e contras de todas as soluções possíveis e procurar uma adoção que não coloque em risco a estabilidade da Internet.” 7. Os modelos em teste e pré-inscrições existentes ajudam ou atrapalham na resolução das questões técnicas relativas aos IDNs? Os testes iriam interferir na continuidade da operação da Internet? A maioria respondeu afirmando ter a impressão de que a experiência operacional de modelos de teste legítimos pode ser útil para colocar a teoria em prática. Entretanto, alguns reconheceram que certos modelos podem ser considerados como tentativas de forçar a comunidade da Internet a aceitar determinadas tecnologias, independentemente de sua adequação ou qualidade. Além disso, alguns dos que responderam observaram que certos modelos podem conduzir à criação de um espaço de nomes alternativo além daquele reconhecido por ICANN, o que por sua vez poderia confundir os usuários. Um respondente observou que as expectativas dos usuários em relação aos modelos de teste deveriam ser administradas cuidadosamente. Os usuários podem ter a impressão de que os testes são uma parte operacional da Internet e podem considerar falhas técnicas durante os testes como problemas operacionais, ao invés de uma característica normal do processo de teste. John Klensin observa também que "modelos de teste mal definidos" e "envie somente 8 estratégias" "criam o risco de prejudicar softwares existentes, dentro dos padrões e desenvolvidos...”. Veja também a sua resposta (Pergunta 16 da pesquisa A). Stefan Probst afirma que o teste de Verisign colocou os registradores numa posição difícil. Por um lado, a ISOC desencorajou registros de IDNs antes da adoção de padrões, ao passo que por outro lado, a falta de registros significa a perda de clientes. Provavelmente os registrantes tiveram de optar entre dar atenção à ISOC ou proteger os seus nomes da pirataria cibernética. 8. Será que as línguas naturais são tão complexas, ricas e variadas que um verdadeiro sistema de IDNs que corresponda inteiramente às expectativas dos usuários está além da atual capacidade tecnológica? O problema pode ser resolvido de modo a não interferir na operação de todo o sistema de nomes de domínio? Vários respondentes observaram que o sistema de nomes de domínio nunca teve o propósito de servir como um “serviço de diretório que pudesse encontrar o resultado adequado a uma busca em idioma natural, de maneira consistente. Embora o DNS tenha sido desenvolvido desde o início para reduzir determinados erros associados a idiomas ,como por exemplo sua insensibilidade a casos, ele não é capaz de distinguir entre variantes de palavras, mesmo em inglês, ou outras nuances do idioma. Por esta razão, vários respondentes acreditam que assuntos que envolvem línguas naturais e as expectativas de usuários específicas do contexto estão fora do escopo do exercício de IDNs. Eles consideram os nomes de domínio simplesmente como identificadores, e o exercício de IDNs como uma maneira de obter apoio para uma maior variedade de escritas a serem usadas como identificadores no DNS. Outros, entretanto, acreditam que a natureza de nomes de domínio evoluiu desde as suas origens, e que hoje os nomes de domínio representam a identidade de uma pessoa ou corporação na Web – uma evolução de identificador para identidade. Como tal, o DNS deveria tentar incorporar as regras das línguas naturais na medida do possível. Camadas de serviços de diretórios acima do DNS são uma maneira de atender essa necessidade crescente. Os respondentes advertem que as questões relativas às línguas naturais devem ser abordadas em nível local. Os usuários devem ser informados sobre os limites do DNS para moderarem as suas expectativas. E a injeção de regras das línguas naturais deve ser feita de forma a não ameaçar a estabilidade da Internet, particularmente solapando a abordagem de nomes exclusivos. 9. Como as diferentes tecnologias afetam o limite de tamanho dos nomes de domínio? Se houver, quais são as soluções possíveis? Os nomes de domínio são limitados a 255 octetos, com não mais de 63 octetos por segmento (p. ex., entre períodos). Diferentes representações de conjuntos de caracteres exigem um número diferente de octetos. Como os códigos de escritas não-latinas muitas vezes exigem mais octetos do que as escritas latinas, os IDNs não podem continuar sendo nomes de domínio em escrita latina. Especialistas estão analisando vários algoritmos de compressão para aumentar o número de caracteres não latinos que podem ser incluídos em um nome de domínio. 10. Os IDNs apresentam problemas especiais para a operação técnica
das bases de dados WHOIS? Em caso afirmativo, quais problemas? Quais
são as soluções possíveis? Verisign GRS observa que os “serviços WHOIS precisam ser internacionalizados se os nomes de domínio que eles contêm forem internacionalizados. Uma possibilidade é internacionalizar o próprio protocolo WHOIS, juntamente com clientes e servidores. Outra possibilidade é adotar a abordagem IDNA: os IDNs seriam armazenados em um formato ACE e os clientes WHOIS converteriam o material de usuários internacionalizados para o formato ACE, antes de fazer buscas em um servidor WHOIS”. Vários respondentes acreditam que uma solução de longo prazo exige uma abordagem do ponto de vista do servidor. 11. Existem tecnologias relativas a IDNs cobertas por patentes ou outros direitos de propriedade intelectual? Nesse caso, isso interferiria na implementação de IDNs? De acordo com Register.com, “diversas companhias reivindicam direitos de propriedade intelectual sobre vários aspectos da solução para IDN”. Por exemplo, recentemente Walid recebeu um requerimento de patente sobre aspectos da solução de IDNA sob análise da IETF. Walid afirmou que se a IETF adotar um padrão que exija o uso de tecnologia patenteada por Walid, esta irá conceder “uma licença não-exclusiva sobre termos e condições razoáveis e não-discriminatórios, baseada no princípio da reciprocidade...” Vários respondentes expressaram sua preocupação com esta patente, e observaram que a ITF estaria levando-a em conta ao determinar se iria ou não prosseguir com a solução de IDNA. Neteka tem requerimentos de patentes pendentes quanto à sua tecnologia multilíngue. Neteka argumenta que sua tecnologia está disponível como fonte pública. Stefan Probst apóia somente a adoção de tecnologias disponíveis sob uma licença de fonte pública. 12. Você participa ou participou do processo de padronização para IDNS, promovido pela IETF? Muitos respondentes são participantes ativos do grupo de trabalho para IDN da IETF. 13. Uma vez que a IETF adote um padrão IDN, com que velocidade este será incorporado a aplicativos tais como browsers? Existe algum problema em antecipar essa incorporação? O que a IETF e ICANN podem fazer para facilitar o processo de incorporação? Vários respondentes observaram que a rapidez da adoção dependerá da solução escolhida e do tratamento de direitos de propriedade intelectual relativos ao padrão. Walid acredita que se a IETF adotar uma abordagem do ponto de vista do cliente, a maioria das solicitações poderia ser atendida “em alguns meses”. Por outro lado, Walid afirma que uma solução do ponto de vista do servidor irá seguir um ciclo de desenvolvimento muito mais lento. Uma solução que se baseasse na infraestrutura poderia levar até 10 anos para se desenvolver plenamente. De acordo com os respondentes, a IETF pode facilitar o processo adotando um padrão da maneira mais rápida e prudente possível. ICANN deve apoiar os esforços da IETF e o padrão resultante. 14. Os padrões da IETF serão interoperáveis com outros padrões da IDN? O que pode ser feito para eliminar problemas de interoperabilidade (pressupondo que nem todos os ccTLDs adotem o padrão IETF)? Os respondentes concordam que, tendo em vista a grande variedade de abordagens para IDNs, é improvável que o padrão IETF seja interoperável com todos os desdobramentos da IETF. Neteka afirma que a sua solução híbrida reduzirá os problemas de interoperabilidade. Walid observa que a adoção de padrões técnicos é voluntária, mas as forças do mercado irão promover a padronização e uniformidade. Verisign, entretanto, acredita que “a concordância com um padrão IETF deve ser um requisito para todos os operadores de ccTLDs e gTLDs que agora estão oferecendo IDNs”. 15. Existem outras necessidades dos usuários finais referentes a IDNs que devam ser levadas em conta? Os respondentes identificaram as seguintes necessidades: compatibilidade retroativa, uso de IDNs em contextos de documentos, como URLs incluídas em documentos HTML ou XML; e a introdução de símbolos e pontuação. Neteka também recomendou que se reconheça a falta de sofisticação técnica do usuário médio, e a incapacidade de instalar modificações maiores ou plug-ins. 16. Existem outras questões técnicas que nós deveríamos conhecer? Mais uma vez, Neteka destacou as dificuldades que os usuários encontrarão com as soluções voltadas para clientes, particularmente que “a média dos usuários não entenderá por que poderá acessar nomes de domínio multilíngües usando o seu sistema existente”. John Klensin observou que ICANN deveria “proteger a Internet contra abusos do DNS, que criam o risco de prejudicar softwares existentes, dentro dos padrões e já desenvolvidos, ou o risco de atribuição de nomes ambíguos ou não-exclusivos. Os riscos nestas áreas de modelos de teste mal definidos, estratégias como “basta enviar 8”, encorajamento de pirataria multilíngue, etc., são consideráveis e foram indicados repetidamente para ICANN. A solução é começar a advertir os domínios relevantes sobre o impacto, com a possibilidade de iniciar um processo de redelegação ... caso continuem estimulando estes esforço. Se, como eu suspeito, ICANN realmente não tiver autoridade para fazê-lo, então deve admitir o fato e sair dessa área até que os diversos obstáculos sejam removidos do mercado”. Pesquisa B: Questões políticas 1. Qual é a sua opinião sobre a importância dos IDNs? Quem irá se beneficiar deles? Existe qualquer prova empírica desses benefícios? Quem será prejudicado pelos IDNs? De modo geral, os respondentes tiveram uma atitude muito positiva em relação aos IDNs. Eles observaram que a maior parte da população mundial não usa a escrita latina como sua escrita nativa. Portanto, os IDNs aumentarão o acesso e o uso da Internet. Além disso, os IDNs irão facilitar o acesso a esta população por parte de empresas e organizações que agora são limitadas por nomes de domínio em escrita latina. Os respondentes não puderam apresentar outras evidências empíricas dessas posições, além do grande número de registros de IDNs até o momento. Ao mesmo tempo, alguns respondentes observaram que os IDNs irão aumentar a oportunidade de pirataria cibernética. JPNIC sugeriu que os IDNs podem dificultar o uso da Internet por deficientes visuais: “usuários com deficiências visuais ter dificuldade de identificar os nomes de domínio que pretendem digitar, porque pronunciar o alfabeto inglês é muito mais simples do identificar caracteres japoneses com a voz, entre mais de 2000 caracteres diferentes”. 2. A tradução ou transliteração de uma marca registrada ou outro nome constitui uma violação? A resposta a esta pergunta varia, de acordo com o sistema jurídico? Tratados de marcas registradas e outros acordos internacionais dizem respeito a este assunto? Existem variações nacionais quanto à lei para marcas registradas, porém em muitos países a tradução ou transliteração de uma marca pode ser considerada uma infração, caso ela confunda o púbico em relação à origem dos bens e serviços. Além disso, em países que reconhecem a diluição, uma tradução ou transliteração poderia ser considerada diluição. Um respondente mencionou que este assunto foi discutido no Artigo 6bis da Convenção de Paris. JPNIC observa que a tradução ou transliteração de marcas registradas
estrangeiras para o japonês pode resultar em uma seqüência de caracteres
que viola uma marca japonesa. A maioria dos respondentes observou que quando há novas oportunidades
de registros, as novas oportunidades de pirataria cibernética se apresentam
por si só. Alguns acrescentaram que IDNs não seriam mais suscetíveis
à ciberpirataria do que escritas latinas. Outros temem que determinadas
escritas apresentem problemas especiais. De acordo com a JPNIC, alguns
caracteres Kanji são muito semelhantes a outros. Alguns respondentes
afirmaram que o acréscimo de novas escritas pode representar um desafio
lingüístico para proprietários de marcas que monitorarem violações de
suas marcas. Alguns dos respondentes afirmaram que todas as três providências são igualmente importantes. Outros opinaram que um mecanismo efetivo para resolução de disputas seria a medida mais importante, embora os procedimentos não tenham necessariamente que se conformar com a atual forma da UDRP da ICANN. Pelo menos um respondente observou que providências de “sunrise” seriam problemáticas porque envolveriam os registros/registradores nas disputas de nomes de domínio. 5. Quais grupos dentro e fora da ICANN deveriam analisar estas questões políticas? E como deveriam proceder? De modo geral, os respondentes apoiaram a análise da ICANN sobre os assuntos levantados pelos IDNs. Alguns respondentes esperam ver um grupo de trabalho vigoroso para IDN na DNSO, e a formulação de recomendações concretas. Os respondentes também estimularam os esforços cooperativos com MINC e outros grupos como IETF, CDNC, e JET. 6. Quais outros assuntos políticos são levantados pelos IDNs? Como ICANN pode tratar deles, se for o caso? Um respondente sugeriu que a comunicação entre registradores e registros precisa ser melhorada. Muitos respondentes sugeriram uma revisão e possível modulação da UDRP. Em particular, ICANN deve analisar novos provedores de resolução de disputas, capazes de tratar disputas de IDN. JPNIC também observou que uma determinada escrita muitas vezes é usada em mais de um país, isto é, além do território de um registro particular de código de país. 1. Quais serviços IDN você oferece no momento? Por favor, forneça materiais (tais como material promocional ou publicidade) descrevendo estes serviços. Quanto você cobra por estes serviços, e como estes preços se comparam com os preços do equivalente não-IDN? Vários respondentes oferecem servidos de registro de IDNs. TWNIC oferece registros gratuitamente; Verisign GRS e JPNIC cobram o mesmo valor por registros IDN e registros ASCII. Vários respondentes oferecem softwares e outras ferramentas relativas a atividades IDN, inclusive resolução IDN. 2. Você está registrando [IDN].gTLD, [IDN].ccTLD, ou [IDN].[IDN]? Favor descrever outros nomes de domínio que eventualmente estiver registrando. Walid está registrando [IDN].[IDN]; Verisign GRS está registrando [IDN]. gTLD; vários registros de países estão registrando [IDN].ccTLD. JPNIC também relatou que está oferecendo registros de seqüências mistas de caracteres japoneses e latinos. 3. Você também registra nomes de domínio em escrita latina, ou apenas IDNs? Walid oferece somente registros IDN, ao passo que a maioria dos respondentes registra nomes tanto em escrita latina quanto IDN. 4. Os IDNs que você registrou estão ativos? Isto é, eles podem ser resolvidos em um aplicativo de um usuário final, ou você está apenas oferecendo o pré-registro de IDNs? Os IDNs registrados no registro Walid podem ser usados com o software Walid WorldConnect do cliente. Os usuários de TWNIC podem resolver os seus IDNs em aplicativos da rede e e-mail. Os IDNs da JPNIC podem ser resolvidos em aplicativos de usuários finais. No modelo de teste da Verisign GRS, os IDNs ainda são designados como um domínio de terceiro nível, onde a resolução é possível em um aplicativo do usuário final. 5. Caso ainda não esteja ativo, quando imagina que estará? Alguns responderam que estarão ativos assim que a IETF adotar um padrão. 6. Qual tecnologia você utiliza, ou pretende utilizar, para o seu sistema IDN? Verisign GRS e TWNIC utilizam o NamePrep para converter os IDNs em Códigos Compatíveis com ASCII (ACE). TWNIC também está testando o software BIND para apoiar códigos de 8 bit (códigos nativos) e códigos UTF-8. Walid usa sua tecnologia WorldConnect, WorldTools, e WorldApp para transformações ACE. Neteka oferece NeDNS e NeR2R, numa abordagem híbrida 7. Como você sabe, a IETF ainda não adotou padrões relativos a IDNs. Se adotar, você pretende cumprir estes padrões quando forem adotados? Explique a sua política em relação a padrões técnicos. A maioria dos respondentes afirmou que irá cumprir os padrões IETF quando forem adotados. 8. Quantos registros você realizou em cada uma das escritas que você registra? A maioria dos respondentes tratou esta informação como confidencial. De acordo com as informações de Walid, a Verisign GRS registrou 920.000 IDNs nos primeiros cinco meses de operação (resposta de Walid à pergunta 1 da Pesquisa B). JPNIC afirmou que até meados de maio havia recebido 50.000 requerimentos de nomes de domínio em japonês, e 350.000 em escrita latina. 9. Em quais tipos de escrita você está aceitando registros? Quais outras escritas você pretende registrar no futuro? Walid registra árabe, hindi e chinês simplificado. Verisign GRS aceita as 39 escritas Unicode. TWNIC aceita escrita latina, chinês tradicional e chinês simplificado. JPNIC aceita a escrita latina e japonesa. 10. Você teve mais complicações com algumas escritas do que com outras? Que tipo de complicações? Vários respondentes disseram que não tiveram mais complicações com determinadas escritas. Neteka afirma que existem algumas complicações, e que é importante envolver a comunidade local para criar um conjunto aceitável de normas para desenvolver nomes de domínio na língua nativa. TWNIC indica que existem complicações decorrentes da normatização entre chinês simplificado e tradicional. JPNIC observa que muitas palavras japonesas possuem grafias múltiplas, ou seja, Katakana, Hiragana, e Kanji. Além disso, diferentes palavras japonesas podem ter a mesma grafia em uma seqüência ASCII porque têm a mesma pronúncia. Da mesma forma, existem alguns caracteres japoneses que são obsoletos. 11. Entre os registrantes que registram IDNS com você, qual porcentagem já possui nomes de domínio registrados em escrita latina? A maioria dos respondentes não possui estes dados, porém Walid estima que 80% dos registrantes de IDN já possuem um registro em escrita latina. Outro respondente indica que esta porcentagem pode até ser maior – muito próxima de 100%. 12. Antes que você começasse a aceitar registros de IDNs, você fez estudos de mercado para determinar a procura por serviços IDN? Em caso afirmativo, o que os estudos revelaram? Vários respondentes realizaram pesquisas de mercado, e descobriram que havia interesse em IDNs, particularmente entre os clientes existentes. Verisign GRS observa que até 2003, dois terços de todos os usuários da Internet serão não-falantes de inglês. 13. Até que ponto você está oferecendo serviços IDN como uma medida defensiva, ou seja, porque outros estão oferecendo estes serviços? Até que ponto os registrantes estão fazendo registros de IDNs como um medida defensiva, isto é, para evitar a pirataria cibernética? Os respondentes indicaram que estão oferecendo serviços IDN porque percebem uma procura significativa por eles. Ao mesmo tempo, Verisign GRS reconheceu que desenvolveu o seu modelo de teste em parte “como uma medida defensiva contra abordagens alternativas para IDNs, que poderiam ser contrárias ao princípio de uma única raiz de DNS e poderiam não ser compatíveis com o trabalho de desenvolvimento de padrões pelo grupo de trabalho da IETF para IDNs”. Em relação à motivação de seus clientes, os respondentes indicaram que os registrantes obtiveram registros de IDNs porque eram “interessantes e importantes”, entretanto, vários respondentes reconheceram a prevenção contra pirataria. 14. Que providências você está tomando para impedir a pirataria cibernética? Você possui um mecanismo de “sunrise” ativo? Neste caso, descreva como ele funciona. Você concorda com a UDRP da ICANN? Se não, você está disposto a concordar com ela ou com alguma variante? Verisign GRS usa a UDRP da ICANN. Além disso, durante o período de teste, o Registrador NSI conservou o direito de rescindir um registro se, no prazo de 45 dias a partir da data de registro, receber uma objeção formal ao registro por escrito. Walid exige que os registrantes concordem com termos semelhantes à UDRP. TWINIC usa a UDRP da ICANN, e durante um período de sunrise reservou algumas palavras para evitar o registro abusivo. Tonga opera o seu registro estritamente em uma base de “primeiro a chegar – primeiro a ser atendido”. É difícil aplicar a UDRP da ICANN em razão de sua política de respeito à confidencialidade do registrante. JPNIC usou um período sunrise de um mês quando começou a aceitar registros de IDNs, e agora usa uma versão adaptada da UDRP. 15. Você oferece uma base de dados WHOIS? Neste caso, para que finalidade? Se não, você pretende fazê-lo no futuro próximo? Walid, Verisign GRS, NSI Registrar, e TWNIC, todos oferecem algum tipo de base de dados WHOIS para IDNs. JPNIC oferece uma base de dados WHOIS para resolver problemas técnicos, transparência de registro, fornecer informações para fins de resolução de disputas, e análises em estudos acadêmicos. 16. Como você está fazendo o marketing de seus serviços IDN? Até que ponto os clientes são informados do caráter experimental dos atuais padrões e modelos de teste de IDNs? NSI Registrar promove um marketing em nível nacional. Walid vende os
seus serviços basicamente criando relacionamentos com ccTLD, registros
de gTLD e parceiros regionais. Os respondentes disseram que informam
aos registrantes que ainda não se adotaram padrões para IDNs. TWNIC enfatizou que o desenvolvimento de um sistema IDN deve considerar a cultura e os costumes do usuário local, não apenas soluções para problemas técnicos. A entidade instou para que a IETF adote urgentemente padrões para IDNs, e apoiou o desenvolvimento de modelos de testes locais por consórcios regionais. Neteka observou a preocupação entre a comunidade técnica "de que servidores iriam sucumbir com os requerimentos multilíngües enviados. As diferentes implementações indicam que esta preocupação é muito exagerada”. Stefan Probst observa que havia discrepâncias entre os serviços que Verisign GRS e Register.com oferecem em seus websites e os serviços realmente disponíveis no momento. O WG para IDNs se beneficiou muito com as contribuições recebidas daqueles que responderam à pesquisa. Cada uma ajudou a definir o escopo do trabalho que ainda precisa ser feito. Tendo em vista a necessidade de mais informações, o grupo de trabalho propõe as seguintes etapas para o futuro levantamento de fatos: (1) Em razão do tempo reduzido disponível para responder às pesquisas e do desejo do Grupo de Trabalho em ouvir todas as vozes da comunidade da Internet, o WG gostaria de receber outras respostas às pesquisas de 30 de abril. Particularmente, o WG está ansioso para ter as opiniões de engenheiros e usuários em geral. Favor enviar as suas respostas às pesquisas até 21 de julho de 2001. (2) O Grupo de Trabalho gostaria de receber comentários sobre este Relatório de Status. Envie seus comentários sobre o relatório até 31 de julho de 2001. (3) O WG planeja editar perguntas de acompanhamento até o final de junho. Se você tiver sugestões de perguntas, envie-as ao Grupo de Trabalho tão logo quanto possível. Favor enviar suas respostas às pergunta de acompanhamento até 31 de julho de 2001. O Grupo de Trabalho pede desculpas por estes prazos reduzidos, mas ele precisa dessas informações a fim de concluir o seu próximo relatório para o Conselho Administrativo para a reunião da ICANN em setembro, no Uruguai. B.Grupos de trabalho para IDNs Vários respondentes da pesquisa disseram que ICANN deveria manter grupos de trabalho para IDNs numa base de longo prazo. Naturalmente, ICANN transfere ao Grupo de Trabalho para IDNs da IETF a definição de padrões técnicos para IDNs. Ao mesmo tempo, paralelamente ao WG para IDNs da IETF, grupos de trabalho das organizações de apoio poderão se dedicar a outras questões políticas de IDNs. O Grupo de Trabalho Interno do Conselho Administrativo terá prazer em receber recomendações da ICANN e das comunidades da Internet sobre a estrutura e tarefa desses grupos de trabalho. Além disso, os membros do Grupo de Trabalho Interno do Conselho Administrativo acreditam que este grupo deve continuar monitorando o desenvolvimento de IDNs e atuar como um elo de ligação entre o Conselho Administrativo e outros grupos de trabalho para IDNs e a comunidade de IDNs como um todo.
Masanobu Katoh Comentários sobre o layout, estrutura e funcionalidade
deste site Página atualizada em 1 de junho de 2001 |
