Hola de nuevo :-) Les escribo porque en la reunión de hoy estuvimos conversando sobre las diferentes respuestas que podemos recibir desde los ccTLD cuando se consulta por la disponibilidad de inscripción de un dominio. Hasta el momento, la respuesta que estamos usando sirve para informar: 1) Disponible: en este caso el ccTLD nos envía una respuesta que informa las alternativas disponibles de inscripción para el nombre consultado. Cada alternativa viene acompañada con una “URL de inscripción”. 2) Inscritos: en este caso el ccTLD nos envía una respuesta que informa los dominios actualmente inscritos con el nombre solicitado. Cada dominio inscrito viene acompañado con una “URL de consulta” de los datos del dominio inscrito. Pero ¿qué pasa si el ccTLD no puede informar dominios disponibles y tampoco inscritos?, unos ejemplos que hemos conversado es el caso de IDN o nombres muy cortos o nombres muy largos. En esos casos, creo que la respuesta desde el ccTLD debería incluir una descripción que nos permita informar al usuario final lo que pasó con la consulta a dicho ccTLD. De esta forma, en la interfaz web se puede mostrar la respuesta de ese país con un símbolo de advertencia u otro que indique que el nombre consultado no se puede inscribir y si el usuario quiere más información, se despliega la descripción que recibimos desde el ccTLD. Para la implementación, por el momento creo que en el cliente (REST API) que está desarrollando Alejandra me parece que es una buena idea usar su propuesta: código de respuesta HTTP 400 (Bad Request), pero sugiero que venga acompañado de un texto que describe la condición que no se cumplió. ¿Qué opinan? Sobre los casos que se podrían considerar, en la reunión de hoy se mencionaron los siguientes: - Caracteres no soportados (caso de implementación de IDN) - Nombre más corto que el mínimo permitido - Nombre más largo que el largo máximo permitido - Nombre prohibido de inscribir (se me acaba de ocurrir) ¿Se les ocurren otros casos? De antemano, muchas gracias por sus comentarios. Saludos, -- José Urzúa Jefe Desarrollo de Sistemas NIC Chile - Universidad de Chile
Gracias José por compilar la discusión en forma tan clara. En principio no
veo otros casos una vez enviada la consulta. Pero tal como tu decías en la
llamada si mal no recuerdo, habría que hacer el doble chequeo sobre el
string de que no contenga puntos y demás símbolos. Tal vez ese error (si se
las arreglan para saltear el primer chequeo) debería configurarse también.
On Mon, Apr 5, 2021 at 3:14 PM José Urzúa
Hola de nuevo :-)
Les escribo porque en la reunión de hoy estuvimos conversando sobre las diferentes respuestas que podemos recibir desde los ccTLD cuando se consulta por la disponibilidad de inscripción de un dominio. Hasta el momento, la respuesta que estamos usando sirve para informar:
1) Disponible: en este caso el ccTLD nos envía una respuesta que informa las alternativas disponibles de inscripción para el nombre consultado. Cada alternativa viene acompañada con una “URL de inscripción”.
2) Inscritos: en este caso el ccTLD nos envía una respuesta que informa los dominios actualmente inscritos con el nombre solicitado. Cada dominio inscrito viene acompañado con una “URL de consulta” de los datos del dominio inscrito.
Pero ¿qué pasa si el ccTLD no puede informar dominios disponibles y tampoco inscritos?, unos ejemplos que hemos conversado es el caso de IDN o nombres muy cortos o nombres muy largos. En esos casos, creo que la respuesta desde el ccTLD debería incluir una descripción que nos permita informar al usuario final lo que pasó con la consulta a dicho ccTLD. De esta forma, en la interfaz web se puede mostrar la respuesta de ese país con un símbolo de advertencia u otro que indique que el nombre consultado no se puede inscribir y si el usuario quiere más información, se despliega la descripción que recibimos desde el ccTLD.
Para la implementación, por el momento creo que en el cliente (REST API) que está desarrollando Alejandra me parece que es una buena idea usar su propuesta: código de respuesta HTTP 400 (Bad Request), pero sugiero que venga acompañado de un texto que describe la condición que no se cumplió. ¿Qué opinan?
Sobre los casos que se podrían considerar, en la reunión de hoy se mencionaron los siguientes:
- Caracteres no soportados (caso de implementación de IDN) - Nombre más corto que el mínimo permitido - Nombre más largo que el largo máximo permitido - Nombre prohibido de inscribir (se me acaba de ocurrir)
¿Se les ocurren otros casos?
De antemano, muchas gracias por sus comentarios.
Saludos, -- José Urzúa Jefe Desarrollo de Sistemas NIC Chile - Universidad de Chile
-- Buscador mailing list Buscador@lactld.org https://mail.lactld.org/mailman/listinfo/buscador
-- *Miguel Ignacio Estrada* General Manager *M:* gm@staff.lactld.org *T:* +598 2 604 22 22 *W:* www.lactld.org
¡Hola!
Por si sirve de referencia, los aspectos sintácticos que se revisan en .gt
son:
1. Elementos válidos:
1. El nombre de dominio puede estar compuesto por elementos de los
siguientes conjuntos :
1. Letras: *a b c d e f g h i j k l m n o p q r s t u v w x y z*
2. Dígitos: *0 1 2 3 4 5 6 7 8 9*
3. Símbolos: *-*
4. Internacional: á, é, í, ó, ú, ü y ñ
2. El nombre de dominio no puede empezar, ni terminar con guión (*-*)
3. No se permiten nombres de dominio que comiencen con *xn--*
4. No se permiten nombres de dominio que contengan guiones en la 3a y
4a posición.
5. No se distinguen entre mayúsculas y minúsculas.
2. Longitud:
1. La longitud mínima es de 1 elemento (sin incluir los subdominios).
2. La longitud máxima es de 63 elementos punycode (sin incluir los
subdominios).
En su momento recuerdo haber revisado los RFCs correspondientes para ver
qué era un nombre de dominio válido de forma universal:
https://tools.ietf.org/html/rfc1035#page-8 y
https://tools.ietf.org/html/rfc5891#page-8.
Entiendo que el único símbolo válido es el guión, por lo que cualquier otro
símbolo (paréntesis, corchetes, comas, etc. pueden ser filtrados).
Sobre las letras creo que lo mejor es no meterse a ello, puesto que cada
ccTLD tiene sus propias políticas.
Saludos,
Alejandra
--
[image: Photograph]
*Alejandra Reynoso*Investigación & Desarrollo | Dominios .gt
*P:* +502 23688565
*E:* alejandra.reynoso@cctld.gt
18 Ave. 11-95 Zona 15, V.H. III. (A-109)
Guatemala, Guatemala
www.gt
On Mon, Apr 5, 2021 at 12:49 PM Miguel Ignacio Estrada
Gracias José por compilar la discusión en forma tan clara. En principio no veo otros casos una vez enviada la consulta. Pero tal como tu decías en la llamada si mal no recuerdo, habría que hacer el doble chequeo sobre el string de que no contenga puntos y demás símbolos. Tal vez ese error (si se las arreglan para saltear el primer chequeo) debería configurarse también.
On Mon, Apr 5, 2021 at 3:14 PM José Urzúa
wrote: Hola de nuevo :-)
Les escribo porque en la reunión de hoy estuvimos conversando sobre las diferentes respuestas que podemos recibir desde los ccTLD cuando se consulta por la disponibilidad de inscripción de un dominio. Hasta el momento, la respuesta que estamos usando sirve para informar:
1) Disponible: en este caso el ccTLD nos envía una respuesta que informa las alternativas disponibles de inscripción para el nombre consultado. Cada alternativa viene acompañada con una “URL de inscripción”.
2) Inscritos: en este caso el ccTLD nos envía una respuesta que informa los dominios actualmente inscritos con el nombre solicitado. Cada dominio inscrito viene acompañado con una “URL de consulta” de los datos del dominio inscrito.
Pero ¿qué pasa si el ccTLD no puede informar dominios disponibles y tampoco inscritos?, unos ejemplos que hemos conversado es el caso de IDN o nombres muy cortos o nombres muy largos. En esos casos, creo que la respuesta desde el ccTLD debería incluir una descripción que nos permita informar al usuario final lo que pasó con la consulta a dicho ccTLD. De esta forma, en la interfaz web se puede mostrar la respuesta de ese país con un símbolo de advertencia u otro que indique que el nombre consultado no se puede inscribir y si el usuario quiere más información, se despliega la descripción que recibimos desde el ccTLD.
Para la implementación, por el momento creo que en el cliente (REST API) que está desarrollando Alejandra me parece que es una buena idea usar su propuesta: código de respuesta HTTP 400 (Bad Request), pero sugiero que venga acompañado de un texto que describe la condición que no se cumplió. ¿Qué opinan?
Sobre los casos que se podrían considerar, en la reunión de hoy se mencionaron los siguientes:
- Caracteres no soportados (caso de implementación de IDN) - Nombre más corto que el mínimo permitido - Nombre más largo que el largo máximo permitido - Nombre prohibido de inscribir (se me acaba de ocurrir)
¿Se les ocurren otros casos?
De antemano, muchas gracias por sus comentarios.
Saludos, -- José Urzúa Jefe Desarrollo de Sistemas NIC Chile - Universidad de Chile
-- Buscador mailing list Buscador@lactld.org https://mail.lactld.org/mailman/listinfo/buscador
-- *Miguel Ignacio Estrada* General Manager *M:* gm@staff.lactld.org *T:* +598 2 604 22 22 *W:* www.lactld.org -- Buscador mailing list Buscador@lactld.org https://mail.lactld.org/mailman/listinfo/buscador
Hola Gracias por el trabajo, José, y las respuestas iniciales. Yo mencioné que es posible que adicionalmente algunos ccTLD tengan restricciones: - Lista de palabras reservadas (muy parecido a prohibido de inscribir) - Palabras consideradas ofensivas (es más difícil de generar una lista, y un poco arbitrario, pero se puede comenzar a trabajar) - Otros conceptos, por ejemplo apellidos (de nuevo, en los casos en que aplique, habrá que saber cómo distinguen los ccTLD que no lo permiten, por ejemplo "blanco" (color) de "Blanco" (apellido)). La responsabilidad de definir si una cadena de símbolos no aplica en un ccTLD deberá ser de la respuesta generada por el ccTLD, pero es probable que aún así, sea necesario referir al cliente interesado al ccTLD para más detalles, pues no sé si en todos los ccTLD están definidos absolutamente todos los casos en que el registro "no aplica", o hay casos que pasan a algún tipo de análisis. Seguimos... El lun, 5 de abr. de 2021 a la(s) 12:14, José Urzúa (jose@nic.cl) escribió:
Hola de nuevo :-)
Les escribo porque en la reunión de hoy estuvimos conversando sobre las diferentes respuestas que podemos recibir desde los ccTLD cuando se consulta por la disponibilidad de inscripción de un dominio. Hasta el momento, la respuesta que estamos usando sirve para informar:
1) Disponible: en este caso el ccTLD nos envía una respuesta que informa las alternativas disponibles de inscripción para el nombre consultado. Cada alternativa viene acompañada con una “URL de inscripción”.
2) Inscritos: en este caso el ccTLD nos envía una respuesta que informa los dominios actualmente inscritos con el nombre solicitado. Cada dominio inscrito viene acompañado con una “URL de consulta” de los datos del dominio inscrito.
Pero ¿qué pasa si el ccTLD no puede informar dominios disponibles y tampoco inscritos?, unos ejemplos que hemos conversado es el caso de IDN o nombres muy cortos o nombres muy largos. En esos casos, creo que la respuesta desde el ccTLD debería incluir una descripción que nos permita informar al usuario final lo que pasó con la consulta a dicho ccTLD. De esta forma, en la interfaz web se puede mostrar la respuesta de ese país con un símbolo de advertencia u otro que indique que el nombre consultado no se puede inscribir y si el usuario quiere más información, se despliega la descripción que recibimos desde el ccTLD.
Para la implementación, por el momento creo que en el cliente (REST API) que está desarrollando Alejandra me parece que es una buena idea usar su propuesta: código de respuesta HTTP 400 (Bad Request), pero sugiero que venga acompañado de un texto que describe la condición que no se cumplió. ¿Qué opinan?
Sobre los casos que se podrían considerar, en la reunión de hoy se mencionaron los siguientes:
- Caracteres no soportados (caso de implementación de IDN) - Nombre más corto que el mínimo permitido - Nombre más largo que el largo máximo permitido - Nombre prohibido de inscribir (se me acaba de ocurrir)
¿Se les ocurren otros casos?
De antemano, muchas gracias por sus comentarios.
Saludos, -- José Urzúa Jefe Desarrollo de Sistemas NIC Chile - Universidad de Chile
-- Buscador mailing list Buscador@lactld.org https://mail.lactld.org/mailman/listinfo/buscador
-- "Tomo lo bueno, no importa de quién venga; desecho lo malo, no importa de quién venga" "El amor y el odio afectan más profundamente a quien lo profesa que a quien lo recibe" ------------- Rafael (Lito) Ibarra Twitter: litoibarra Skype: lito.ibarra El Salvador (SV) Tel. (503) 2223-5016
Creo que lo ideal es mantener un listado de posibles errores, para que
tengamos un estándar y quien necesite un error diferente solicite que se
agregue a la lista, por si hay otros que también necesiten usarlo. Esto con
el fin de estandarizar los mensajes a mostrar y evitar confusiones.
Saludos,
Ale
--
[image: Photograph]
*Alejandra Reynoso*Investigación & Desarrollo | Dominios .gt
*P:* +502 23688565
*E:* alejandra.reynoso@cctld.gt
18 Ave. 11-95 Zona 15, V.H. III. (A-109)
Guatemala, Guatemala
www.gt
On Mon, Apr 5, 2021 at 5:09 PM Lito Ibarra
Hola
Gracias por el trabajo, José, y las respuestas iniciales.
Yo mencioné que es posible que adicionalmente algunos ccTLD tengan restricciones: - Lista de palabras reservadas (muy parecido a prohibido de inscribir) - Palabras consideradas ofensivas (es más difícil de generar una lista, y un poco arbitrario, pero se puede comenzar a trabajar) - Otros conceptos, por ejemplo apellidos (de nuevo, en los casos en que aplique, habrá que saber cómo distinguen los ccTLD que no lo permiten, por ejemplo "blanco" (color) de "Blanco" (apellido)).
La responsabilidad de definir si una cadena de símbolos no aplica en un ccTLD deberá ser de la respuesta generada por el ccTLD, pero es probable que aún así, sea necesario referir al cliente interesado al ccTLD para más detalles, pues no sé si en todos los ccTLD están definidos absolutamente todos los casos en que el registro "no aplica", o hay casos que pasan a algún tipo de análisis.
Seguimos...
El lun, 5 de abr. de 2021 a la(s) 12:14, José Urzúa (jose@nic.cl) escribió:
Hola de nuevo :-)
Les escribo porque en la reunión de hoy estuvimos conversando sobre las diferentes respuestas que podemos recibir desde los ccTLD cuando se consulta por la disponibilidad de inscripción de un dominio. Hasta el momento, la respuesta que estamos usando sirve para informar:
1) Disponible: en este caso el ccTLD nos envía una respuesta que informa las alternativas disponibles de inscripción para el nombre consultado. Cada alternativa viene acompañada con una “URL de inscripción”.
2) Inscritos: en este caso el ccTLD nos envía una respuesta que informa los dominios actualmente inscritos con el nombre solicitado. Cada dominio inscrito viene acompañado con una “URL de consulta” de los datos del dominio inscrito.
Pero ¿qué pasa si el ccTLD no puede informar dominios disponibles y tampoco inscritos?, unos ejemplos que hemos conversado es el caso de IDN o nombres muy cortos o nombres muy largos. En esos casos, creo que la respuesta desde el ccTLD debería incluir una descripción que nos permita informar al usuario final lo que pasó con la consulta a dicho ccTLD. De esta forma, en la interfaz web se puede mostrar la respuesta de ese país con un símbolo de advertencia u otro que indique que el nombre consultado no se puede inscribir y si el usuario quiere más información, se despliega la descripción que recibimos desde el ccTLD.
Para la implementación, por el momento creo que en el cliente (REST API) que está desarrollando Alejandra me parece que es una buena idea usar su propuesta: código de respuesta HTTP 400 (Bad Request), pero sugiero que venga acompañado de un texto que describe la condición que no se cumplió. ¿Qué opinan?
Sobre los casos que se podrían considerar, en la reunión de hoy se mencionaron los siguientes:
- Caracteres no soportados (caso de implementación de IDN) - Nombre más corto que el mínimo permitido - Nombre más largo que el largo máximo permitido - Nombre prohibido de inscribir (se me acaba de ocurrir)
¿Se les ocurren otros casos?
De antemano, muchas gracias por sus comentarios.
Saludos, -- José Urzúa Jefe Desarrollo de Sistemas NIC Chile - Universidad de Chile
-- Buscador mailing list Buscador@lactld.org https://mail.lactld.org/mailman/listinfo/buscador
-- "Tomo lo bueno, no importa de quién venga; desecho lo malo, no importa de quién venga" "El amor y el odio afectan más profundamente a quien lo profesa que a quien lo recibe" ------------- Rafael (Lito) Ibarra Twitter: litoibarra Skype: lito.ibarra El Salvador (SV) Tel. (503) 2223-5016 -- Buscador mailing list Buscador@lactld.org https://mail.lactld.org/mailman/listinfo/buscador
Hola Muchas gracias por sus comentarios. Les informo que he ido agregando cambios al documento e incluí una sección con este listado: https://docs.google.com/document/d/1JrGdUvRCN-9LCc3XAkUrwTI6-LDhXNP02FnWVBu-... También agregué una descripción sobre la integración con un ccTLD: https://docs.google.com/document/d/1JrGdUvRCN-9LCc3XAkUrwTI6-LDhXNP02FnWVBu-... Por otro lado, creo que si tenemos un listado con los posibles mensajes de validación en la consulta en los ccTLD, bastaría que desde los ccTLD solo nos indiquen un código de respuesta para los casos de error y la aplicación de LACTLD genera la glosa asociada a dicho error de este listado que hemos armado, preocupándose además de generarla en el idioma que corresponda. ¿Qué opinan? Saludos, -- José Urzúa Jefe Desarrollo de Sistemas NIC Chile - Universidad de Chile
El 07-04-2021, a las 13:17, Alejandra Reynoso
escribió: Creo que lo ideal es mantener un listado de posibles errores, para que tengamos un estándar y quien necesite un error diferente solicite que se agregue a la lista, por si hay otros que también necesiten usarlo. Esto con el fin de estandarizar los mensajes a mostrar y evitar confusiones.
Saludos, Ale
--
Alejandra Reynoso Investigación & Desarrollo | Dominios .gt P: +502 23688565 E: alejandra.reynoso@cctld.gt 18 Ave. 11-95 Zona 15, V.H. III. (A-109) Guatemala, Guatemala www.gt
On Mon, Apr 5, 2021 at 5:09 PM Lito Ibarra
wrote: Hola Gracias por el trabajo, José, y las respuestas iniciales.
Yo mencioné que es posible que adicionalmente algunos ccTLD tengan restricciones: - Lista de palabras reservadas (muy parecido a prohibido de inscribir) - Palabras consideradas ofensivas (es más difícil de generar una lista, y un poco arbitrario, pero se puede comenzar a trabajar) - Otros conceptos, por ejemplo apellidos (de nuevo, en los casos en que aplique, habrá que saber cómo distinguen los ccTLD que no lo permiten, por ejemplo "blanco" (color) de "Blanco" (apellido)).
La responsabilidad de definir si una cadena de símbolos no aplica en un ccTLD deberá ser de la respuesta generada por el ccTLD, pero es probable que aún así, sea necesario referir al cliente interesado al ccTLD para más detalles, pues no sé si en todos los ccTLD están definidos absolutamente todos los casos en que el registro "no aplica", o hay casos que pasan a algún tipo de análisis.
Seguimos...
El lun, 5 de abr. de 2021 a la(s) 12:14, José Urzúa (jose@nic.cl) escribió: Hola de nuevo :-)
Les escribo porque en la reunión de hoy estuvimos conversando sobre las diferentes respuestas que podemos recibir desde los ccTLD cuando se consulta por la disponibilidad de inscripción de un dominio. Hasta el momento, la respuesta que estamos usando sirve para informar:
1) Disponible: en este caso el ccTLD nos envía una respuesta que informa las alternativas disponibles de inscripción para el nombre consultado. Cada alternativa viene acompañada con una “URL de inscripción”.
2) Inscritos: en este caso el ccTLD nos envía una respuesta que informa los dominios actualmente inscritos con el nombre solicitado. Cada dominio inscrito viene acompañado con una “URL de consulta” de los datos del dominio inscrito.
Pero ¿qué pasa si el ccTLD no puede informar dominios disponibles y tampoco inscritos?, unos ejemplos que hemos conversado es el caso de IDN o nombres muy cortos o nombres muy largos. En esos casos, creo que la respuesta desde el ccTLD debería incluir una descripción que nos permita informar al usuario final lo que pasó con la consulta a dicho ccTLD. De esta forma, en la interfaz web se puede mostrar la respuesta de ese país con un símbolo de advertencia u otro que indique que el nombre consultado no se puede inscribir y si el usuario quiere más información, se despliega la descripción que recibimos desde el ccTLD.
Para la implementación, por el momento creo que en el cliente (REST API) que está desarrollando Alejandra me parece que es una buena idea usar su propuesta: código de respuesta HTTP 400 (Bad Request), pero sugiero que venga acompañado de un texto que describe la condición que no se cumplió. ¿Qué opinan?
Sobre los casos que se podrían considerar, en la reunión de hoy se mencionaron los siguientes:
- Caracteres no soportados (caso de implementación de IDN) - Nombre más corto que el mínimo permitido - Nombre más largo que el largo máximo permitido - Nombre prohibido de inscribir (se me acaba de ocurrir)
¿Se les ocurren otros casos?
De antemano, muchas gracias por sus comentarios.
Saludos, -- José Urzúa Jefe Desarrollo de Sistemas NIC Chile - Universidad de Chile
-- Buscador mailing list Buscador@lactld.org https://mail.lactld.org/mailman/listinfo/buscador
-- "Tomo lo bueno, no importa de quién venga; desecho lo malo, no importa de quién venga" "El amor y el odio afectan más profundamente a quien lo profesa que a quien lo recibe" ------------- Rafael (Lito) Ibarra Twitter: litoibarra Skype: lito.ibarra El Salvador (SV) Tel. (503) 2223-5016 -- Buscador mailing list Buscador@lactld.org https://mail.lactld.org/mailman/listinfo/buscador
participants (4)
-
Alejandra Reynoso
-
José Urzúa
-
Lito Ibarra
-
Miguel Ignacio Estrada