Resumen

  • ICANN aplica dos controles distintos: las cadenas ASCII de una o dos letras no se admiten al presentar la solicitud; una cadena solicitada de dos caracteres, o una de sus variantes, puede ser rechazada después si el panel la considera visualmente similar a una cadena ASCII de dos caracteres o a una variante de esta.
  • La herramienta SSE hace una preselección, pero el panel adopta la decisión final. El resultado debería identificar la pareja decisiva, la escritura y la representación analizadas, cualquier comparación omitida, la motivación del panel y el plazo de impugnación de 21 días.

El solicitante más expuesto a este filtro no es necesariamente quien intenta registrar dos letras ASCII. Ese caso es más sencillo: el sistema debe detener la cadena durante la presentación. El caso difícil aparece cuando la solicitud utiliza dos caracteres de otra escritura, cumple las reglas técnicas correspondientes y, en apariencia, no ocupa ningún código ASCII de dos letras.

La Guía del Solicitante de 2026 no considera suficiente esa diferencia formal. Durante la String Similarity Evaluation, la cadena principal y sus variantes se comparan con un universo que incluye todas las cadenas ASCII de dos caracteres y sus variantes. Si el panel determina que la cadena solicitada o una de sus variantes es similar a una de ellas, la solicitud no continúa.

Hay, por tanto, dos puertas. Una comprueba una prohibición directa. La otra exige un juicio de semejanza visual. Agrupar ambas bajo la frase «cadena bloqueada» ocultaría precisamente la información que el solicitante necesita para comprobar si la decisión es correcta.

La primera puerta pregunta por identidad y elegibilidad

La sección 7.2.1 de la Guía incluye todas las demás cadenas ASCII de una o dos letras entre las que no pueden solicitarse. La FAQ pública de ICANN repite esa regla. Según la sección 7.2.1.1, el sistema comprueba automáticamente la cadena introducida y, cuando la identifica dentro de la categoría bloqueada, impide continuar con ella.

Este control puede documentarse con pocos elementos: la cadena recibida, su forma normalizada, la categoría que coincidió, la versión de la lista y la hora de la comprobación. No hace falta una valoración sobre tipografía o percepción humana. La pregunta es si la entrada coincide con una categoría expresamente no permitida.

Una solicitud IDN de dos caracteres plantea otra cuestión. Su etiqueta no es una cadena ASCII de dos letras, pero ella —o una variante— puede ser considerada visualmente similar a una de esas cadenas o a sus variantes en la String Similarity Evaluation. La decisión ya no depende de una coincidencia literal.

El expediente público debería indicar cuál de las dos puertas actuó. Sin esa distinción, una impugnación no sabe si debe examinar la normalización, la categoría de bloqueo, la relación de variante, la representación visual o el razonamiento del panel.

La comparación alcanza a variantes que el público podría no ver

El alcance de la SSE no termina en la cadena principal. La Guía incorpora las variantes asignables y, con límites, las variantes bloqueadas. Para la relación estudiada aquí, el paquete de hechos congelado establece la comparación con todas las cadenas ASCII de dos caracteres y sus variantes.

La consecuencia más importante es que la pareja decisiva puede no ser la pareja de etiquetas principales. Una variante del solicitante puede parecerse a la cadena ASCII; la cadena principal puede parecerse a una variante de la cadena de comparación; o la relación puede surgir entre dos variantes. Además, la sección 7.10.3 dispone que todo el conjunto de variantes comparte el resultado de la evaluación. Un único borde de similitud puede transmitir el efecto a todas las etiquetas asociadas a la solicitud.

Por eso, una resolución que diga solamente «similar a una cadena ASCII de dos caracteres» resulta incompleta. Debería señalar:

  • las etiquetas principales y variantes que formaron la pareja;
  • sus A-label, U-label y puntos de código;
  • la escritura, la forma en mayúsculas o minúsculas y la relación de variante;
  • la categoría de similitud aplicada; y
  • qué miembros del conjunto de variantes heredan el resultado.

Esta lista es una recomendación editorial para obtener una traza reconstruible, no una descripción de los campos que ICANN publicará. El paquete no establece la forma de un resultado individual de 2026.

Los datos SSE muestran por qué contar caracteres no basta

ICANN publicó el 23 de julio de 2026 la versión 1.0 de sus datos y directrices para la evaluación de similitud. Los expertos de cada escritura compararon elementos dentro de una escritura, entre escrituras relacionadas y frente a caracteres ASCII en mayúsculas y minúsculas. Las definiciones de variantes del RZ-LGR se integraron para producir conjuntos potenciales que la herramienta puede detectar.

La sección dedicada a ASCII documenta relaciones como i frente a l, m frente a rn, n frente a ri y vv frente a w. No todas tienen la misma fuerza. Algunas proceden directamente del análisis experto; otras se incorporan por variantes o transitividad. También puede aparecer una semejanza al convertir a mayúsculas aunque las formas minúsculas sean más fáciles de distinguir.

Estos ejemplos explican la mecánica, no describen solicitudes reales de la ronda de 2026. El paquete de fuentes de este artículo no incluye resultados individuales, tasas de falsos positivos ni decisiones de impugnación. Sería incorrecto presentar una pareja ilustrativa del documento técnico como si ya hubiera provocado el rechazo de una candidatura.

Lo que sí demuestra el material oficial es la necesidad de conservar la representación exacta evaluada. Una palabra genérica como «parecido» no permite distinguir una relación directa de una relación impuesta por transitividad, ni una variante formal de una semejanza visual dependiente de la fuente.

La herramienta reduce el universo; no dicta el veredicto

Las Directrices SSE de julio de 2026 asignan a la herramienta una función de preselección. La herramienta genera conjuntos potenciales y un informe para el panel. El panel puede añadir, ajustar o eliminar conjuntos y debe justificar esas decisiones. Si una cadena no aparece en el informe, todavía requiere revisión manual junto con sus variantes.

La división verificada es concreta: la herramienta aporta la preselección, mientras que el panel puede modificar los conjuntos con razones y debe revisar manualmente las cadenas ausentes del informe. El paquete no añade afirmaciones sobre la composición profesional del panel ni prescribe una prueba de contexto de visualización.

La trazabilidad debe unir ambos pasos. El resultado debería mostrar si la pareja fue detectada en la preselección, qué categoría calculó la herramienta, qué decidió el panel y qué razón explica cualquier diferencia. Un número sin la pareja subyacente no es una motivación; una conclusión humana sin la directriz aplicada tampoco lo es.

Las Directrices permiten omitir determinadas comparaciones entre variantes bloqueadas cuando la confusabilidad entre escrituras es manifiestamente baja. Esa facultad evita trabajo sin valor, pero también crea un punto de decisión. El registro debería identificar la comparación omitida, el criterio utilizado y quién aprobó la omisión.

Dos relaciones producen dos consecuencias en la misma categoría

La tabla 7-5 diferencia los resultados. Cuando la cadena solicitada es igual a una cadena ASCII de dos caracteres, o es una variante de ella, la solicitud no se acepta. Cuando es visualmente similar pero no es una variante, no puede continuar.

La diferencia importa porque la identidad o la condición formal de variante no es el mismo hallazgo que la similitud visual, aunque ambos detengan la solicitud en esta categoría. El glosario de ICANN describe la categoría como espacio de posibles futuros ccTLD; el paquete congelado no infiere de ello ningún proceso adicional.

Esa descripción es una regla del programa, no una sentencia sobre propiedad. Las fuentes no prueban que ICANN, la Agencia de Mantenimiento ISO 3166 o un Estado sea propietario de una etiqueta de dos letras. Tampoco convierten una reserva técnica en soberanía. Conviene mantener separadas la coordinación del namespace y cualquier teoría jurídica más amplia.

El plazo de 21 días exige razones entregadas a tiempo

El solicitante puede impugnar el resultado dentro de los 21 días siguientes a su recepción si considera que hubo un error factual, procedimental o del sistema. Si el error se confirma, la evaluación se repite teniendo en cuenta la decisión de la impugnación. Si no se confirma, el resultado original permanece.

Un plazo breve solo funciona cuando la notificación contiene lo necesario para evaluarla. El solicitante no debería tener que descubrir durante esos 21 días qué variante produjo la alerta, qué forma tipográfica se mostró o si el panel añadió una pareja que la herramienta no había identificado.

El registro mínimo debería contener:

  1. el control activado: bloqueo directo o evaluación de similitud;
  2. la pareja exacta de etiquetas principales o variantes;
  3. las formas normalizadas, A-label, U-label, puntos de código, escrituras y casos;
  4. la categoría de similitud y la directriz aplicada;
  5. el informe de preselección y cualquier cambio del panel;
  6. las comparaciones omitidas y su justificación;
  7. el efecto sobre todo el conjunto de variantes; y
  8. la fecha de transmisión, el límite para impugnar y un identificador estable.

Esta propuesta es análisis editorial. Aplica la doctrina de Heng Lu según la cual un control capaz de terminar una solicitud debe dejar un registro reconstruible de la regla, los hechos, el razonamiento, el responsable y el recurso. La doctrina no demuestra que ICANN haya cometido un error, que exista un falso positivo o que una mayor transparencia cambie el resultado.

El filtro de dos caracteres puede proteger la claridad del DNS sin convertirse en una caja negra. Para ello, el expediente debe mantener una diferencia sencilla: una cadena ASCII corta puede quedar prohibida al entrar; una etiqueta distinta puede quedar excluida más tarde por un juicio visual motivado. Cuando ICANN publica qué puerta actuó y qué pareja decidió el caso, la regla puede auditarse sin tratar la herramienta como árbitro.

Fuentes