Resumen

  • La revisión 15 de RDAP Extensions propone que el contacto registrado solicite la obsolescencia de su extensión y que el IESG pueda solicitarla para cualquier entrada. IANA anotaría una fecha; esa acción no desinstala implementaciones.
  • La revisión 07 sobre versionado permite publicar versiones admitidas, relaciones de reemplazo, valores predeterminados y fechas start/end, además de identificar la versión de una respuesta y recibir una preferencia del cliente.
  • La retirada necesita un recibo que vincule autoridad registral, estado verificable de cada servidor, demanda observada y clientes que siguen siendo desconocidos. Es una propuesta editorial de Daniel Kade, no texto normativo del IETF.

Hay un atractivo burocrático en la palabra obsoleto. Convierte una transición difícil en una propiedad de inventario: antes estaba vigente; ahora ya no. Para un registro de identificadores, esa claridad es una virtud. Para una red de software independiente, es apenas el comienzo.

RDAP sirve datos de registros de dominios y de números mediante autoridades distintas, redirecciones y referencias. Un cliente puede cruzar varios servidores sin haberse identificado ante ninguno. Esa apertura explica por qué el proyecto draft-ietf-regext-rdap-extensions-15 insiste en pensar las extensiones como piezas de un ecosistema completo, no como una interfaz privada entre dos partes conocidas.

El documento se publicó el 13 de agosto de 2026 y continúa como borrador de trabajo de REGEXT con intención de Standards Track. El Datatracker pide una revisión por una cuestión planteada en el grupo y no registra un Area Director responsable. El proyecto complementario sobre versiones, revisión 07 del 31 de julio, también es un Internet-Draft. Ninguno es un RFC ni prueba una implantación.

Lo que puede decidir el registro

Los identificadores de extensión funcionan como espacios de nombres. Se incluyen en rdapConformance y conducen a la definición que un cliente necesita. Son opacos: un número final puede parecer una versión sin revelar si existe continuidad, ruptura o simple coincidencia con otro nombre.

La revisión 15 propone añadir Deprecation Date al registro de IANA. El contacto que figura en una entrada podría pedir la obsolescencia de su propia extensión. El IESG podría pedirla para cualquiera. La fecha seguiría la sintaxis de día completo de RFC 3339. El modelo identifica al solicitante competente y al custodio del asiento.

Ese poder es real, pero estrecho. Cambia el significado público del identificador. No ordena a cada operador que borre una ruta, un miembro JSON o un parámetro. Tampoco llega al ordenador donde un cliente conserva una biblioteca antigua. Una decisión registral puede orientar la retirada sin ser la retirada.

El borrador pide fechar el 21 de agosto de 2025 dos perfiles ICANN que el registro actual ya muestra como OBSOLETED: icann_rdap_response_profile_0 e icann_rdap_technical_implementation_guide_0. El registro, actualizado el 1 de septiembre de 2026, muestra asimismo sus sucesores de versión 1, pero no una columna independiente de fecha. El dato no permite reprochar nada a IANA: la instrucción sigue dentro de un borrador.

La política de alta también delimita la función. Specification Required y Expert Review exigen una referencia estable, disponible y suficiente para que dos implementadores puedan interoperar. La revisión 15 propone tres expertos como mínimo y una segunda comprobación para cada solicitud. El examen protege el vocabulario compartido; no certifica todos los programas que acabarán usándolo.

Lo que puede prometer un servidor

El proyecto de versionado convierte el anuncio de migración en datos. versioning_help, dentro de /help, puede exponer versiones, documentos, relaciones de predecesor y sucesor, la opción predeterminada y momentos de inicio y fin. versioning_data identifica la versión aplicada a una respuesta concreta. versioning_list permite que el cliente pida una versión.

La separación evita inferencias engañosas. Que una versión sea compatible no significa que sea la predeterminada. Que una respuesta use el formato nuevo no demuestra que el antiguo haya desaparecido. Que el cliente no pida nada puede significar que acepta el valor por defecto, no que entiende la transición.

El miembro end expresa cuándo el servidor planea dejar de admitir un objeto de versión. Después de ese instante debe retirarlo de su inventario anunciado. Sin end, no hay una expiración planificada. Esta precisión pertenece al servidor. No convierte su reloj en una declaración sobre todos los consumidores externos.

Para una ruptura, la revisión 07 recomienda una fase intermedia. El servidor ofrece a la vez el elemento antiguo y su sustituto, explica la relación y concede tiempo para migrar. Puede cambiar primero el valor predeterminado, conservando la selección antigua hasta el final. El diseño reduce el salto; no decide cuánto dura “tiempo suficiente” para una población desconocida.

El proyecto de extensiones reconoce el límite de forma explícita: sin relación entre cliente y servidor, no existe una manera absoluta de demostrar que un cambio incompatible carecerá de efecto en todos los clientes. Esa falta de certeza no debe convertirse en derecho de veto perpetuo. Una interfaz heredada también acumula costes, contradicciones y riesgos.

Evidencia sin vigilancia

Los registros operativos pueden contar solicitudes explícitas de la versión vieja, observar errores y distinguir servidores o caminos de referencia. Los clientes administrados pueden confirmar una actualización. Los trabajos periódicos pueden ensayarse antes de la fecha. Son pruebas útiles, siempre que indiquen su alcance.

Guardar indefinidamente cada consulta RDAP, dirección y firma de software sería una mala respuesta. Una transición no justifica crear un historial mundial de lectores. La publicación debería usar intervalos, agregados, exclusiones y retención limitada. Cero observaciones en una muestra significa cero en esa muestra, no cero dependencias en Internet.

Un recibo de retirada

El recibo comenzaría con la entrada exacta, la persona u órgano que solicitó el cambio, el asiento de IANA y la fecha. Después describiría el reemplazo: documentos, elementos afectados, compatibilidad y significado. La relación entre dos nombres tendría que declararse; no se adivinaría por el sufijo.

Cada operador añadiría su propio tramo: instantáneas fechadas de /help, cambio del valor predeterminado, inicio y fin anunciados, ejemplos de versioning_data, tratamiento de peticiones antiguas, regla de reversión y confirmación posterior de retirada. El plan y la observación no compartirían casilla.

La demanda aparecería como medición acotada: periodo, nodos cubiertos, método de agregación, versiones antiguas observadas, clientes conocidos pendientes y límites de privacidad. La decisión final nombraría a su responsable y admitiría lo que no puede saber.

Así se evita un doble abuso. El operador no puede decir “IANA me obligó” cuando tomó su propia decisión de despliegue. El cliente tampoco puede invocar una dependencia invisible para congelar la interfaz sin aportar un caso reproducible. La coordinación queda documentada sin inventar una autoridad central de extremo a extremo.

Fuentes