Resumen

  • La entrada actual de WHOIS 2.10.7 de AFRINIC, fechada el 29 de noviembre de 2022, enumera JSContact como nueva función RDAP.
  • La guía pública de RDAP explica consultas, cliente y redirección fuera de región, pero no identifica versión, miembro de respuesta, señal de conformidad ni mecanismo de petición para JSContact.
  • La brecha es documental: no demuestra cómo responde hoy el endpoint ni atribuye una falta técnica a AFRINIC.

Dos documentos, dos alcances

La entrada de lanzamiento y la guía de servicio no compiten; responden a preguntas distintas. El changelog de AFRINIC declara actual a WHOIS 2.10.7, con fecha de 29 de noviembre de 2022. Entre las notas figuran mejoras relativas a la conformidad con el perfil RDAP de la NRO y una nueva función RDAP, JSContact. Esa es una afirmación pública de cambio, no un manual de interoperabilidad.

La guía RDAP sí actúa como manual de acceso. Identifica el endpoint y las familias de consulta para direcciones IP, autnums, DNS inverso y entidades. Remite a NicInfo como cliente de línea de comandos y describe el HTTP 301 cuando el recurso pertenece a otra región. Un operador puede aprender dónde hacer una consulta ordinaria y cómo interpretar esa redirección.

Sin embargo, el lector no encuentra en esa guía RDAP JSContact, jCard, rdapConformance ni version. Por eso la documentación pública no permite enlazar la frase del changelog con una respuesta concreta: no dice qué representación de contactos se anuncia, si una versión importa, si hay una solicitud optativa, ni qué marca confirmaría en la respuesta la representación elegida.

Esa frase debe quedarse exactamente ahí. No equivale a afirmar que el endpoint no admite JSContact. No equivale a decir que AFRINIC incumple un perfil NRO o un estándar. No equivale a atribuir un fallo de cliente, una exposición de datos o un perjuicio. Esta investigación no ha tomado una respuesta en vivo del endpoint. Describe lo que los dos documentos publicados dejan unido y lo que todavía dejan separado.

La historia impide escoger una versión por intuición

La prudencia no es puramente formal. En abril de 2022 ya existía un borrador de Internet del IETF para usar JSContact en respuestas RDAP. Era un trabajo en curso, no una regla que AFRINIC debiera adoptar. Aquel texto hablaba de una extensión para contactos de entidad y empleaba la denominación jscard. Que apareciera antes del lanzamiento de noviembre no convierte al borrador en prueba de implementación.

La versión actual del borrador emplea otra arquitectura verbal: jscontact_card, selección de representación a petición del cliente, señalización de rdapConformance y etapas para pasar de jCard a JSContact. Es un comparador técnico útil, porque explica por qué el nombre del formato no agota la experiencia del cliente. Pero no es una vara retrospectiva para medir la nota de AFRINIC de 2022.

También el registro de IANA distingue actualmente versiones mayores 1.0 y 2.0 de JSContact. No señala una versión servida por AFRINIC. Sí confirma que la palabra JSContact puede requerir contexto adicional cuando se usa para describir una interfaz pública.

La posición más fuerte de AFRINIC merece aparecer antes de la recomendación. El registro no tiene obligación de exponer configuraciones internas, datos de contacto, pruebas privadas ni planes de transición. Puede mantener una guía corta, centrada en consultas habituales, y un changelog breve, centrado en cambios. Ninguna de las dos páginas promete por sí sola una matriz completa de compatibilidad.

Pero una ficha de disponibilidad de extensión permitiría que ambas páginas se refirieran al mismo objeto público. Podría registrar la revisión de servicio y documentación; la representación y versión anunciadas cuando proceda; cualquier método público de solicitud; una señal de respuesta; el estado de compatibilidad; la referencia al perfil aplicable; el comportamiento de reserva documentado; y una fecha, responsable, corrección y sustitución. No necesita enseñar una tarjeta de contacto real, credenciales, registros de tráfico ni decisiones internas.

Un recibo pequeño evita una conclusión grande

La propuesta no obliga a AFRINIC a elegir JSContact frente a jCard, ni prescribe un calendario. Sólo separa tres cosas que una etiqueta breve puede confundir: que se anunció una función, que un cliente puede pedir una representación y que una respuesta documenta cuál recibió.

Esa separación protege al registro y a quien lo consulta. AFRINIC conserva el control de su servicio. El lector recibe una superficie pública que puede verificar y corregir. La documentación gana continuidad sin convertirse en una ventana indiscreta sobre la operación.

Sources

  1. AFRINIC Online Services Changelog
  2. Guía del servicio RDAP de AFRINIC
  3. IETF draft-ietf-regext-rdap-jscontact-11
  4. IETF draft-ietf-regext-rdap-jscontact
  5. Registro IANA de JSContact