Resumen

  • La colección filtrada Complete es opcional y reúne tanto operaciones exitosas como solicitudes processed que no tendrán nuevas actualizaciones. Estar en ella no demuestra que todo haya salido bien.
  • El estado individual complete exige éxito en las acciones correspondientes y en las CDNs descendientes afectadas. Una respuesta processed no puede convertirse en éxito confirmado al subir por la cadena.
  • La hora estimada de finalización sirve para planificar, no para acreditar el resultado. Esta interfaz no exige sincronizar los relojes de las CDNs interconectadas.
  • Invalidación, purga, precarga, cancelación y borrado del informe producen efectos distintos. La decisión posterior debe identificar cuál necesita realmente.
  • El ejemplo de sustitución de contenido es análisis de la especificación, no un incidente observado ni una medición de adopción.

La señal que permite empezar otra cosa

Un editor quiere sustituir material en las mismas URLs. Primero pide a su socio de distribución que purgue el contenido anterior. Después prevé precargar el nuevo. La separación parece sencilla: una operación debe terminar antes de que empiece la siguiente.

El socio acepta la petición. Más tarde, el recurso que informa sobre ella aparece en la colección Complete. Un panel puede interpretarlo como una señal suficiente para poner en marcha la precarga. Ya no hay nada que seguir en la cola activa.

Pero el estado individual puede ser processed. La petición ha sido aceptada y no habrá más actualizaciones; la finalización puede ser imposible de confirmar. La pregunta del panel era si el seguimiento continuaría. La del editor es si una purga aún pendiente puede afectar al reemplazo.

Son preguntas diferentes. RFC 8007 permite responder con una capacidad de información limitada sin llamar éxito a esa limitación. El problema aparece cuando otro participante usa el informe como una garantía más fuerte.

Este escenario no atribuye un fallo a una CDN concreta. Expone una decisión posible a partir de la semántica documentada. No se afirma que las redes comerciales apliquen universalmente esta interfaz ni que se haya reproducido una pérdida de contenido.

Dos cierres bajo un mismo nombre

RFC 8007 se publicó en diciembre de 2016 como documento Standards Track de IETF. La ficha del RFC Editor lo identifica como Proposed Standard. Define la parte de disparadores de la interfaz de control CDNI.

Una CDN de origen de la solicitud pide trabajo a otra CDN que distribuye en su nombre. El mecanismo permite solicitar adquisición, invalidación o purga de metadatos y contenido, y consultar el estado de esa actividad. No convierte toda la relación comercial o configuración inicial en una gestión central uniforme.

La CDN receptora mantiene una colección de recursos de estado para cada solicitante. Puede ofrecer vistas filtradas. Si las implementa, debe facilitar sus enlaces desde la colección general. No todos los participantes tienen que ofrecer el mismo conjunto de vistas opcionales.

La vista denominada Complete incluye tareas finalizadas con éxito y solicitudes processed para las que no se comunicarán más cambios. Su pertenencia describe cómo se organiza el seguimiento, no una garantía idéntica para cada operación.

El estado individual complete significa que el comando terminó satisfactoriamente. Processed indica aceptación y ausencia de futuras actualizaciones, incluidas situaciones en las que no puede confirmarse la finalización.

Processed no equivale siempre a fracaso. Tampoco equivale siempre a éxito, a trabajo detenido, a ausencia de actividad o a ausencia de efectos futuros. Es una declaración sobre el límite del informe disponible. Presentar ambos estados como una única confirmación elimina información relevante para quien depende del resultado.

La colección puede servir a un observador que decide qué informes seguir. No basta para quien decide si una condición previa de su propia operación se ha cumplido. El primer compromiso puede cerrarse antes de que el segundo obtenga la respuesta que necesita.

Aceptar crea una referencia, no el resultado

Cuando acepta un disparador, la CDN receptora crea un recurso de estado y devuelve su ubicación con HTTP 201. El solicitante puede inspeccionarlo después. La respuesta acredita la aceptación y proporciona una referencia; no demuestra por sí sola que se haya ejecutado todo el trabajo.

Las ubicaciones deben tomarse de los enlaces devueltos. El solicitante no debe deducir una estructura obligatoria ni construir rutas a partir de ejemplos. Una URI de recurso de estado no puede reutilizarse después de eliminarse, porque la referencia de una petición anterior no debe pasar a identificar otra en silencio.

Una implementación que sigue el progreso puede comunicar espera, actividad y finalmente éxito o fracaso. Cuando no puede proporcionar ese seguimiento, debe explicitarlo mediante processed y colocar el recurso en Complete. También debería aportar una estimación útil de cuándo espera acabar.

Hay situaciones legítimas sin trabajo nuevo. Una purga puede referirse a datos que la red todavía no adquirió. Una precarga puede solicitar datos ya disponibles y válidos. Es correcto que esos casos aparezcan como processed o complete en la colección correspondiente.

Por ello, ni siquiera un estado exitoso mide necesariamente bytes desplazados o almacenamiento borrado. Su sentido depende de la operación solicitada y de su alcance. Un recuento de informes cerrados no sustituye esa lectura.

Una cascada no mejora la certeza por sí sola

Una CDN receptora puede delegar distribución a otras situadas más abajo. Los comandos deben reenviarse a las redes que puedan verse afectadas. La ejecución local de un intermediario no resuelve automáticamente lo que ocurre en sus descendientes.

RFC 8007 prohíbe comunicar complete hasta que el comando sea complete en todas las CDNs descendientes afectadas. Si una de ellas responde processed, las redes intermedias también deben responder processed, no convertir su falta de confirmación en éxito.

Es una restricción sobre el significado de la respuesta agregada. No exige que una autoridad central decida cada paso. Las decisiones de ejecución siguen distribuidas, pero el resultado no puede afirmar una certeza que la cadena no produjo.

El fracaso puede comunicarse cuando aparece en una red o en una descendiente. La lista de errores identifica URLs o patrones afectados. Puede haber información de errores mientras la solicitud continúa activa para otros objetivos.

Las referencias incluidas en los errores deben conservarse exactamente como fueron solicitadas, sin ampliarlas a patrones más generales. Un objetivo fallido no convierte todo en fracaso; un objetivo todavía sin error comunicado no queda por eso probado como exitoso.

Esta separación favorece decisiones selectivas. Un trabajo independiente puede contar con la evidencia suficiente, mientras otro espera un requisito incierto. Declarar todo listo y detenerlo todo son simplificaciones que pueden ignorar el alcance real.

Los requisitos de RFC 7337, un documento Informational, ya pedían informar del éxito o fracaso de las acciones de forma adecuada, también en cascadas. La interfaz de disparadores concreta además cómo expresar una capacidad limitada de seguimiento.

El éxito cambia según la operación

La precarga solicita adquirir metadatos o contenido. La invalidación obliga a revalidar los datos antes de volver a usarlos, sin requerir su eliminación. La purga pide que no permanezcan en la CDN después de atender la solicitud, aunque puedan adquirirse otra vez cuando hagan falta.

El registro vigente de IANA mantiene esas distinciones. Una prohibición de reutilización directa no es la misma consecuencia física que vaciar almacenamiento.

La especificación permite una invalidación complete cuando ciertos servidores de caché afectados están desconectados, siempre que no reutilicen los datos sin revalidarlos al volver. El éxito se apoya en una condición de uso futuro. No afirma que cada dispositivo desconectado ya haya borrado sus datos.

Purga y precarga pueden quedar como processed si el trabajo terminará cuando las cachés regresen al servicio. Si se abandona, debería comunicarse un error. No puede contarse toda tarea de una colección terminal como borrado físico confirmado.

El alcance tampoco es todo Internet. El informe se refiere a los datos y la distribución solicitados. Ningún cambio posterior de estado recupera material que ya se entregó a un receptor.

El orden de envío no gobierna el orden remoto

La CDN receptora controla cuándo empieza el trabajo y a qué ritmo lo realiza. Purga e invalidación deben cubrir datos adquiridos antes de aceptar el comando. No deberían afectar adquisiciones posteriores, pero la CDN solicitante no puede confiar en que esa exclusión sea siempre posible.

La implementación puede decidir cómo tratar una adquisición ya iniciada cuando recibe la orden. El envío de dos solicitudes en secuencia no crea una frontera global inequívoca entre el material antiguo y el nuevo.

RFC 8007 recomienda completar purga o invalidación antes de comenzar la precarga del reemplazo en las mismas URLs. Si ambas actividades se ejecutan en paralelo, el contenido nuevo puede adquirirse y verse afectado inmediatamente por la tarea anterior.

Una distribución en diamante puede duplicar rutas legítimas de adquisición y comandos. La red receptora puede planificar esos comandos por separado. Una rama termina su purga y solicita precarga mientras la de otra sigue activa y afecta al material recién adquirido.

La posibilidad de adquirir de nuevo el contenido ayuda a restaurar disponibilidad. No convierte el primer lanzamiento en una decisión respaldada por la finalización instantánea de todas las operaciones concurrentes.

El editor necesita identificar su condición. Puede requerir éxito confirmado para el alcance del que depende. Puede aceptar conscientemente una estimación bajo un acuerdo local. Puede realizar trabajo que no dependa del objetivo incierto. Ninguna de estas decisiones se deduce únicamente de la palabra Complete.

Una estimación sigue siendo una estimación

La propiedad opcional etime expresa cuándo la CDN receptora espera completar la actividad. Ayuda a organizar el calendario de precarga. No acredita que el resultado exista cuando llegue ese instante.

Los tiempos de creación, modificación y finalización estimada se determinan en la CDN que informa. La interfaz no requiere sincronizar relojes entre CDNs interconectadas. Ordenar sus cifras no basta para reconstruir causalidad entre operadores.

Los participantes pueden acordar cómo interpretar bases de tiempo y márgenes operativos. Esa decisión local no cambia processed por complete. Incluso con relojes alineados, una expectativa no se transforma en un hecho demostrado.

Las peticiones condicionales reducen tráfico de observación. RFC 8007 recomienda ETags para recursos y colecciones; la semántica HTTP y sus reglas de caché explican este mecanismo.

Una respuesta 304 sobre un informe processed sin cambios confirma continuidad de su representación. No aporta el resultado que dejó de prometerse. Consultar repetidamente la misma información no amplía la capacidad de confirmación del otro participante.

Cancelar no deshace lo que ya ocurrió

El servicio debe responder apropiadamente a los comandos de cancelación, pero realizar la cancelación es una capacidad opcional. Puede informar de trabajo inactivo, de aceptación mientras continúa activo o de que la función no está implementada.

Una solicitud pendiente puede empezar antes de procesarse su cancelación. Una activa puede no detenerse inmediatamente. El comando no restaura automáticamente lo borrado ni revierte lo adquirido. Un resultado complete o failed no debe cambiarse retrospectivamente a cancelado.

Las cadenas del protocolo requieren precisión adicional. La corrección técnica verificada 5053 establece cancelling y cancelled; 5054 corrige ecancelled. La corrección editorial 5064 presenta un ejemplo explícito de cancelación separado del borrado del recurso. La explicación en español no debe alterar esos valores.

Eliminar el recurso de estado deja sin referencia consultable y retira sus enlaces de las colecciones. Tiene un efecto parecido a cancelar, pero no mantiene el informe posterior. Un GET fallido después de eliminarlo no permite deducir el resultado anterior.

La retención automática también cierra una ventana de observación. Su duración debe anunciarse cuando se eliminan registros antiguos. Mantenerlos al menos veinticuatro horas es una recomendación, no un mínimo obligatorio sin excepciones. El solicitante debería obtener lo necesario antes de que desaparezca.

Un intercambio protegido puede transportar incertidumbre

Las acciones deben limitarse a los datos del solicitante correspondiente. El caso de diamante reconoce posibles caminos de adquisición legítimos, no autoridad universal para interferir con otras organizaciones.

Las colecciones son propias de cada solicitante y no deben exponerse a otras CDNs. TLS y autenticación remota son necesarios salvo protección alternativa adecuada. Los controles concretos son locales y la relación comercial de confianza queda fuera del protocolo.

Las recomendaciones actuales de TLS sustituyen la orientación anterior citada originalmente. Un canal protegido ayuda a establecer de dónde procede el informe. No confirma que toda acción solicitada haya terminado con éxito.

El marco CDNI, los metadatos y los registros aportan información complementaria. Una entrega correcta o una observación saludable en un punto no acredita el estado de todos los descendientes o dispositivos desconectados.

Fuentes

Las distinciones se basan en documentación primaria. Las propuestas operativas son análisis del autor, no nuevos requisitos.