Muchas gracias por su detallada respuesta. Agrego mis comentarios entre líneas:
El 05-10-2021, a las 14:22, Alberto Leiva Popper <
aleiva@nic.mx> escribió:
Ok, estoy dispuesto a hacer modificaciones al proyecto si tienen una buena razón de ser, pero por lo que entiendo, pareces estar tratando de solucionar el problema en el lugar incorrecto.
Esta es la idea de poder consultar con usted, saber su opinión y recomendación al respecto.
Si tienes un cliente que consulta muchos servidores estándares, y necesitas una funcionalidad que solamente le sirve a tu cliente... la solución no es hacer a los servidores no estándares; la solución es ponerle la funcionalidad al cliente.
Estoy de acuerdo con lo que plantea en forma general. En este tema puntal de RDAP, nos encontramos con una respuesta “Not found” para una consulta de un nombre que *no* puede ser inscrito porque tiene caracteres no soportados en el ccTLD y nos gustaría saber si es posible con RDAP diferenciar ese caso. Esta misma consulta la envié a Francisco Arias de ICANN (también fue recomendación de José Ernesto Grimaldo), Francisco revisó el caso con Gustavo Lozano y Eduardo Alvarez, finalmente me comentaron estas tres alternativas para abordar el tema desde el lado de RDAP:
===== copy&paste=====
1. Crear una extensión de RDAP para este propósito. Por ejemplo, Gustavo sugería: registrableDomain/<domain> , 200 - si, 404 - no. Es probablemente la opción mas limpia, pero require algo de trabajo para documentarla y registrarla en IANA. Una propuesta más compleja, y ahora abandonada la puedes ver en
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-domain-availability-002. Eduardo sugiere usar el "Error response body" como se describe en sección del RFC 9083. No require estandarización, por tanto es relativamente fácil de implementar, basta con que los ccTLDs participantes se pongan de acuerdo en que poner en la respuesta para indicar si el dominio se puede registrar o no. Por no ser estandarizado, solo los participantes que sepan de ello lo entenderán.
3. Registrar un nueve código HTTP. No estoy seguro cuál es el proceso, el registro de los códigos en IANA
https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml dice que se require "IETF review", lo que suena complicado, sobre todo tomando en cuenta que probablemente habría que encontrar una propuesta de uso general.
===== copy&paste=====
Creo que cada una requiere de un tiempo que no será menor y no creo que sea muy rápida la adopción. Me gustaría promover una extensión a RDAP para abordar este caso, pero eso sería un camino paralelo al desarrollo del proyecto del buscador de dominios de LACTLD, pues no podemos esperar a que se haga esa adopción para poder continuar con el desarrollo en nuestro grupo de trabajo.
¿Qué te detiene a analizar la string antes de enviársela al servidor? Para el caso de labels latinoamericanas, me parece que no debería ser mucho problema validar los caracteres permitidos; no parecen ser muchos.
Esta es otra alternativa que también estamos evaluando y probablemente sea la que adoptemos. Con el uso de IDN el conjunto de caracteres permitidos sí pueden ser muchos y distintos en cada ccTLD. Actualmente, la aplicación de LACTLD hace consultas para dominios .CO, .BR y .CL usando RDAP y en los tres el conjunto de caracteres permitidos es diferente. Personalmente creo que lo más probable es que terminemos desarrollando una nueva componente que tendrá la rutina de validación de sintaxis de nombre para cada ccTLD que se integra usando RDAP y en caso de ser válido el nombre, se envía la consulta por RDAP al ccTLD. Tendremos que asumir el costo de mantener actualizada esa componente en los casos que los ccTLD actualicen sus reglas (no es algo tan frecuente), pero pareciera ser mejor que esperar una estandarización de una nueva funcionalidad de RDAP.
Agradezco de sobremanera su tiempo y respuesta a nuestra consulta, nos será de mucha utilidad para las decisiones que debemos tomar.
Saludos,
--
José Urzúa
Jefe Desarrollo de Sistemas
NIC Chile - Universidad de Chile
Hola
Una disculpa; este correo me cayó a la carpeta de spam; acabo de encontrarlo.
Ahora mismo voy a ponerme a investigar si es factible hacer esto.
Alberto
Estimado Alberto
Espero que se encuentre muy bien. Mi nombre es José Urzúa, trabajo para NIC Chile (.CL) y le escribo porque soy parte del grupo de trabajo de LACTLD que está desarrollando un buscador de dominios regional. En este grupo también participa José Ernesto Grimaldo y él nos comentó que podemos contactarlo por el tema que paso a explicar:
De forma muy resumida, el buscador de dominios permite que un usuario pueda saber si un nombre está disponible para inscripción en la región, informando las distintas alternativas que existen en cada ccTLD participante. La aplicación “buscador”, obtiene esa información consultando a cada ccTLD y una forma de consultar es usando el servicio RDAP que algunos países tienen disponible. Por ejemplo, en el caso de .CL tenemos RDAP disponible por medio de reddog. Pero al realizar pruebas con nombres de dominio internacionalizados (IDN) nos encontramos con un caso que nos generó la duda: al consultar por un nombre de dominio que no está inscrito recibo una respuesta con código 404 "Not found”, lo que me parece bien y así podemos mostrar en el buscador que ese nombre está disponible. Pero si consulto por un dominio que “no se puede inscribir”, porque incluye caracteres no soportados por el ccTLD, también obtengo una respuesta con código 404, lo que erróneamente nos lleva a considerar que ese dominio sí está disponible para inscripción, cuando en realidad ese dominio no se podrá inscribir. Estuve mirando los RFC de RDAP y me parece que este comportamiento es acorde a lo que dice el RFC, pero no es acorde al uso que necesitamos en el buscador de dominios de LACTLD.
¿Usted sabe si hay forma de diferenciar estos casos en RDAP?
Por ejemplo, para el caso de .CL, me gustaría poder diferenciar entre las respuestas por:
1- consulta por un dominio IDN disponible que se puede inscribir: diseño-qwerty.cl
2- consulta por un dominio IDN que no se puede inscribir porque no hay soporte para estos caracteres en el ccTLD: diseño-例子.cl
Para el segundo caso, sería ideal que RDAP me responda con un código 400 Bad request u otro que indique que ese nombre no es válido en el ccTLD.
De antemano, agradezco su tiempo y espero se haya entendido la consulta que estamos abordando en el grupo de trabajo.
Saludos cordiales,
--
José Urzúa
Jefe Desarrollo de Sistemas
NIC Chile - Universidad de Chile
Este mensaje contiene información confidencial y se entiende dirigido y para uso exclusivo del destinatario. Si recibes este mensaje y no eres el destinatario por favor elimínalo, ya que difundir, revelar, copiar o tomar cualquier acción basada en el contenido está estrictamente prohibido. Network Information Center, S.A. de C.V., ubicado en Ave. Eugenio Garza Sada 427 Piso 2 Local 1 Col. Altavista, Monterrey, México, C.P. 64840 recaba tus datos personales necesarios para: la prestación, estudio, análisis y mejora del servicio, la realización de comunicaciones y notificaciones; la transferencia y publicación en los casos aplicables; el cumplimiento de la relación existente; así como para la prevención o denuncia en la comisión de ilícitos. Si eres colaborador o candidato a colaborador de NIC México, tus datos serán utilizados para: la creación y administración de tu perfil como profesionista; el otorgamiento de herramientas de trabajo; la realización de estudios; el otorgamiento de programas y beneficios para mejorar tu desarrollo profesional; la gestión y administración de servicios de pago y/o nómina; así como para contacto y/o notificaciones. Si participas en promociones o en estudios podrás dejar de participar. Para mayor información revisa el Aviso de Privacidad (
https://www.nicmexico.mx/es-nicmx-avisosdeprivacidad).
This message contains confidential information and is intended only for the individual named. If you are not the named addressee please delete it, since the dissemination, distribuition, copy or taking any action in reliance on the contents is strictly prohibited. Network Information Center, S.A. de C.V., located on Av. Eugenio Garza Sada 427 Piso 2 Local 1, Col. Altavista, Monterrey, Mexico, CP 64840 collects your personal data which is necessary to: provide, research, analyze and improve the service; send communications and notices; transfer and publish your personal data when applicable; fulfill the existing relationship; prevent or inform in the commission of unlawful acts or events. If the data is processed in your quality of candidate or collaborator of NIC Mexico, the purpose of treatment is to: create and manage your profile as a professional; provide you with working tools; conduct studies; grant benefits and programs to enhance your professional development; manage and administrate payment services and/or payroll; as well as to contact you. If you participate in promotions or surveys you may stop or quit your participation at any time. For more information read the Privacy Note (
https://www.nicmexico.mx/es-nicmx-avisosdeprivacidad/).