Resumen

  • RFC 3648 convierte el orden en estado de una colección, pero deja dos implementaciones válidas para un MOVE con el mismo padre y sin Position.
  • Una migración debe comparar capacidad, tipo de orden, lista completa anterior y posterior y presentación final; ni la existencia de los objetos ni un 2xx demuestran esa equivalencia.

El RFC 3648 distingue dos garantías. En una colección desordenada, PROPFIND no tiene que repetir el mismo orden. En una colección ordenada, el servidor debe enumerar según su secuencia. Cada miembro interno aparece una sola vez y ningún no-miembro puede ocupar una posición. El orden es, por tanto, estado verificable de la colección.

El caso de portabilidad más delicado está escrito en la propia norma. Para un MOVE entre nombres del mismo padre, un servidor puede renombrar y mantener la posición. Otro puede modelar la operación como quitar y añadir; al no existir Position, el nuevo miembro se agrega al final. La versión de texto no declara ganador. Una futura revisión podía acotar la conducta después de obtener experiencia de implementación.

No hay base para atribuir una opción a un producto concreto. El Datatracker, la ficha del RFC Editor, el historial y los errata documentan la norma, no los valores por defecto actuales de servidores. La prueba de migración debe observar cada extremo.

Una colección admite un solo orden. Para representar varias secuencias sobre los mismos recursos hacen falta varias colecciones. El orden es idéntico a través de las URI que acceden a una misma colección y está sujeto a sus bloqueos y ACL. El RFC 5842 permite razonar sobre múltiples enlaces sin confundir identidad del recurso con estado de todas las colecciones que lo referencian.

DAV:ordering-type es una propiedad protegida. DAV:custom afirma que hay una secuencia, pero no que dos aplicaciones comprendan igual su significado. DAV:unordered niega una enumeración repetible. La URI de un tipo de orden no debe recuperarse automáticamente: RFC 3648 advierte que hacerlo podría convertir a los clientes en tráfico contra un objetivo.

Position expresa first, last, before o after y permanece en el registro de campos HTTP de IANA. Reduce la diferencia entre implementaciones, pero su segmento de referencia ha de ser un miembro vigente y distinto. También deben cumplirse autorización y bloqueo. El RFC 3744 aporta el marco de acceso; nombrar una posición no otorga permiso para modificarla.

ORDERPATCH procesa sus instrucciones en el orden del documento y aplica todas o ninguna. Si falla una, recupera el estado previo. Esa atomicidad sólo cubre el cambio en el servidor. Cuando la petición cambia la semántica de orden y omite miembros, coloca primero los declarados y deja el orden relativo del resto al servidor. Una respuesta satisfactoria puede contener deliberadamente una cola no especificada.

La lectura de control es PROPFIND con Depth: 1. Depth: infinity puede intercalar descendientes y no representa una secuencia global plana. El WebDAV original del RFC 2518 fue sustituido por el RFC 4918; esa evolución no elimina la necesidad de observar la colección concreta.

El RFC 3253 aporta versionado DeltaV. Una versión de colección conserva tipo de orden y posiciones de miembros bajo control de versiones. Tras UPDATE o MERGE, los miembros no versionados quedan en posiciones definidas por el servidor. Por ello, igualdad de versión tampoco garantiza igualdad de toda la navegación visible.

El soporte es opcional. OPTIONS, la clase ordered-collections, Allow y propiedades vivas deben comprobarse por recurso; el soporte del padre no se hereda como hecho sobre sus hijos. El RFC 5689 amplía MKCOL, pero poder enviar un cuerpo extendido no prueba que se haya aplicado el orden solicitado.

Los validadores condicionales de RFC 7232 y RFC 9110 pueden cerrar carreras en una implementación. RFC 3648 no define un identificador de revisión exclusivo para el orden. Una migración debe registrar qué validador expuso cada plataforma y qué propiedad protege realmente.

Los segmentos proceden del vocabulario de RFC 2396, actualizado de forma general por RFC 3986. En before/after son operandos de una instantánea de miembros, no identidades permanentes ni credenciales.

La primacía del código en ejecución, la especificación inicial mínima y las capas de realidad de Heng Lu orientan la decisión. La norma permite coordinación sin borrar opciones locales. La migración ha de probar cuál eligió el código, qué estado expuso y qué recibió el usuario.

El expediente debe unir identidad y URI de colección, ordering-type, capacidad, secuencia completa de origen, ACL y bloqueos, bytes exactos de MOVE u ORDERPATCH, Position, respuesta, PROPFIND Depth: 1 de destino, versión o validador disponible y secuencia renderizada. Si sólo se conservaron objetos y códigos, la prueba de orden no se hizo.