Resumen

  • RFC 2352 propuso formar dominios con el nombre oficial, la forma jurídica, la localidad y el país, de modo que la autoridad mercantil o de marcas resolviera el primer derecho al nombre.
  • La unicidad seguía limitada a un contexto legal, mientras que la delegación DNS, el control del servicio y la identidad pública exigían pruebas distintas; el propio editor advirtió la contradicción política y el coste de renombrar.

El atractivo de una dirección que ya viniera juzgada

El protocolo DNS no tiene una respuesta para la pregunta «¿quién merece este nombre?». Puede exigir que dos nodos hermanos no compartan etiqueta, publicar una delegación y contestar consultas exactas. No conoce el alcance de una marca ni la historia de dos empresas homónimas.

Ese vacío llegó a las ventanillas de registro en los años noventa. Los nombres breves de los dominios genéricos parecían escasos y varias organizaciones podían alegar un derecho plausible sobre la misma palabra. RFC 2240 describió el conflicto; RFC 2352 lo sustituyó en mayo de 1998 con una convención más desarrollada.

La propuesta añadía contexto jurídico a la propia ruta. Una limitada británica podía situarse bajo LTD.UK; una marca francesa, bajo TM.FR; una corporación estadounidense incorporaría su Estado. La forma general combinaba un indicador jurídico, una o varias localidades y el código ISO del país.

El nombre completo de la entidad proporcionaría la etiqueta. Se quitaría el sufijo legal porque ya figuraba en la rama superior; los espacios pasarían a guiones y la puntuación se eliminaría o transformaría. La autoridad competente para sociedades o marcas decidiría el derecho de base y el registro DNS correspondiente crearía la entrada.

Era una manera honesta de admitir que el operador del DNS no debía improvisar derecho mercantil. También preservaba que dos entidades pudieran usar las mismas palabras si sus contextos diferían. Sin embargo, una certificación limitada empezó a cargar con una afirmación demasiado amplia: que el nombre legal correcto debía ser también la identidad pública correcta en Internet.

El contexto era parte de la prueba

RFC 2352 sostenía que no surgirían disputas porque los nombres legales eran únicos dentro de su contexto. No había, sin embargo, un registro jurídico mundial.

Una sociedad es única según un territorio, una clase jurídica y una fecha. Las marcas añaden clases de productos, titulares y plazos. El camino propuesto unía decisiones de varios organismos, no una fuente universal de verdad.

La normalización tampoco era inocua. Convertir espacios y signos en guiones produce una etiqueta compatible, pero puede borrar diferencias que el asiento legal conserva. Para demostrar la relación hacen falta al menos cuatro recibos: el registro original, la regla de transformación, la decisión de delegación y el estado publicado de la zona.

También conviene contener la palabra autoridad. En RFC 1034, un servidor es autoritativo para una zona porque posee sus datos completos. Esa función técnica no lo vuelve autoridad sobre personalidad jurídica, prioridad marcaria o legitimidad comercial. Y una respuesta del resolver solo demuestra qué datos se devolvieron para un nombre exacto, no quién controla hoy la empresa, si el sitio es seguro o si la operación del usuario terminó bien.

La objeción quedó dentro del expediente

RFC 2352 fue una contribución independiente e Informational, no un estándar de Internet. El RFC Editor publicó una nota crítica junto al texto.

Señaló que la convención parecía depender de que compañías establecidas sustituyeran dominios familiares por identificadores más largos y engorrosos sin incentivo para hacerlo. La continuidad importaba. RFC 920 ya había advertido que cambiar el dominio de un host dejaba obsoletas tablas, listas de correo, mensajes antiguos, directorios impresos y recuerdos humanos.

La nota vio además una contradicción de mandato. La propuesta reconocía que la estructura de cada espacio nacional correspondía a su ámbito nacional, pero al mismo tiempo prescribía ramas para formas jurídicas, Estados y localidades. La implementación, concluyó el editor, podía no ser políticamente viable.

El problema no era solo estético. Había dos superficies de control. Una oficina jurídica registraba una entidad o una marca. Un administrador DNS elegía las ramas, aceptaba una solicitud y mantenía la delegación. La convención podía transportar evidencia entre ambas; no podía transformar una competencia en la otra.

La evolución posterior no comprimió todas las capas

En 1999 ICANN adoptó la UDRP. La política pide probar similitud confusa con una marca, falta de derecho o interés legítimo y registro y uso de mala fe. Es una vía de adjudicación unida al contrato de registro, no una derivación automática de dominios desde todos los registros mercantiles.

La escritura internacional siguió otra ruta. RFC 2352 constató el límite de los caracteres ASCII. RFC 3490 introdujo después una codificación compatible con ASCII en las aplicaciones, de modo que los servidores DNS no tuvieran que cambiar. Conservó la búsqueda exacta y declaró fuera del protocolo muchas equivalencias lingüísticas, visuales o fonéticas.

Codificar un nombre no resolvió el derecho sobre él. Resolver un litigio no convirtió el registro mercantil en árbol DNS. Obtener una delegación no probó el funcionamiento del servicio.

La utilidad histórica de un diseño no adoptado

La propuesta reconoció un problema real: la misma palabra podía representar identidades legítimas diferentes y una lista plana ocultaba ese contexto. También exigió evidencia jurídica en lugar de una simple declaración del solicitante.

Su límite fue intentar que una jerarquía común absorbiera decisiones que debían seguir localizadas. El DNS necesita unicidad dentro de cada rama, delegación correcta y consulta interoperable. El derecho societario necesita registros responsables dentro de cada jurisdicción. Las marcas necesitan sus pruebas. La identidad pública necesita continuidad en enlaces, certificados, correo y hábitos.

Ningún asiento sustituye a los demás. RFC 2352 quiso trasladar la disputa fuera del registro DNS y acabó mostrando que la disputa reaparece allí donde se decide cómo conectar los registros.

Fuentes y límites

La propuesta y la advertencia están en la ficha de RFC 2352 y el texto de RFC 2352; el antecedente es RFC 2240. La base administrativa y técnica está en RFC 920, RFC 1034, RFC 1035 y RFC 1591. Los mecanismos posteriores son la UDRP de ICANN y RFC 3490. La distinción entre capas sigue los ensayos de Heng Lu sobre capas de realidad y especificación mínima con decisión localizada. Las fuentes no prueban adopción de RFC 2352, titularidad actual de sus ejemplos ni derechos jurídicos presentes.