Zusammenfassung

  • RFC 3648 ordnet jeder Sammlung genau eine Ordnung zu. Mehrere Zugangs-URIs ändern diesen Zustand nicht; mehrere Sammlungen können dieselben Ressourcen dagegen unterschiedlich ordnen.
  • Ein MOVE im selben Elternteil kann die Position erhalten oder als Entfernen plus Hinzufügen ausgeführt werden, was ohne Position zum Anhängen führt. Identität, Operation und beobachtete Reihenfolge müssen getrennt belegt werden.

Der RFC 3648 macht aus Reihenfolge einen Zustand der WebDAV-Sammlung. Eine ungeordnete Sammlung garantiert keine wiederholbare PROPFIND-Aufzählung. Eine geordnete Sammlung muss ihre Ordnung einhalten, jeden internen Member genau einmal enthalten und darf keinen Nicht-Member aufnehmen.

Diese Ordnung ist durch Zugriffswege nicht zu vervielfachen. Sie bleibt für dieselbe Sammlungsressource über alle Zugangs-URIs gleich und unterliegt deren Sperren und Zugriffsregeln. Eine Sammlung besitzt nur eine Ordnung. Wer dieselben Ressourcen in mehreren Sequenzen braucht, verwendet mehrere Sammlungen. Der RFC 5842 zu Bindungen hilft, Ressourcenidentität und Sammlungszustand auseinanderzuhalten.

Beim MOVE innerhalb desselben Elternteils lässt der Standard dennoch zwei Wege offen. Eine Umbenennung kann die Position bewahren. Entfernen und erneutes Hinzufügen löst dagegen die Neumitglied-Regel aus; fehlt Position, landet der Member am Ende. Die Textfassung nennt beide Möglichkeiten und verweist auf mögliche spätere Eingrenzung nach Implementierungserfahrung. Daraus folgt keine Aussage über ein bestimmtes Produkt.

DAV:ordering-type ist geschützt. DAV:custom meldet eine Ordnung, ohne übertragbare Semantik zu versprechen; DAV:unordered verneint Wiederholbarkeit. Eine URI als Ordnungstyp ist ein Bedeutungsbezeichner. Automatisches Abrufen wird aus Sicherheitsgründen nicht verlangt, weil viele Clients sonst gegen ein Ziel gelenkt werden könnten.

Mit Position kann ein Client first, last, before oder after anfordern. Das Feld steht weiterhin im IANA-Register der HTTP-Feldnamen. Der Referenz-Segment muss aber aktueller, anderer Member sein. Sammlung, Sperre und Berechtigung müssen passen. Der RFC 3744 liefert die ACL-Schicht; ein gültiger Name ist kein Änderungsrecht.

ORDERPATCH bearbeitet Anweisungen in Dokumentreihenfolge und gilt ganz oder gar nicht. Bei Fehlern wird der alte Zustand wiederhergestellt. Wechselt die Anfrage jedoch die Ordnungssemantik und nennt nicht alle Member, stehen die genannten zuerst; die relative Reihenfolge des Rests bestimmt der Server. Lokale Atomarität kann also mit absichtlich unvollständiger Ergebnisspezifikation zusammenfallen.

Das unmittelbare Readback ist PROPFIND mit Depth: 1. Depth: infinity darf Nachfahren verschachteln und ist keine flache globale Sequenz. Die WebDAV-Grundlage des RFC 2518 wurde später durch RFC 4918 ersetzt. Ein Statuscode bleibt trotzdem nur Beleg der Protokolloperation, nicht der gerenderten Navigation.

Versionierung setzt eine weitere Grenze. RFC 3253 stellt DeltaV bereit. RFC 3648 speichert Ordnungstyp und Reihenfolge versionskontrollierter Member in der Sammlungsversion. Bei UPDATE oder MERGE bestimmt der Server die Position nicht versionskontrollierter Member. Eine erfolgreiche Wiederherstellung muss deshalb durch eine vollständige Liste ergänzt werden.

Unterstützung ist optional. OPTIONS, die Compliance-Klasse ordered-collections, Allow und Live Properties sind pro Ressource zu prüfen. RFC 5689 erweitert MKCOL-Körper, beweist aber nicht, dass gewünschte Ordnungssemantik wirksam wurde. Konditionale Mechanismen aus RFC 7232 und RFC 9110 können implementierungsspezifisch helfen; RFC 3648 definiert keinen eigenen Ordnungs-Revisionstoken.

Die Segment-Terminologie stammt aus RFC 2396, die allgemeine URI-Syntax wurde durch RFC 3986 fortgeschrieben. Ein Segment in before/after ist Operand gegen aktuelle Mitgliedschaft, keine dauerhafte Identität und kein Berechtigungsnachweis.

Dokumentstatus und Herkunft lassen sich über Datatracker, RFC-Editor-Info, Historie und Errata prüfen. Das ersetzt keine Beobachtung laufender Systeme.

Heng Lus Perspektiven auf den Vorrang laufenden Codes, die minimale Anfangsspezifikation und Realitätsschichten ordnen die Beweise: Standard, Identität, Implementierungswahl, Serverzustand, Darstellung und Nutzung sind getrennte Ebenen. Keine Zugangs-URI und kein grüner MOVE-Status darf die fehlenden Ebenen vertreten.

Der Beleg muss Sammlungsidentität und Zugangs-URIs, Bindungskontext, ordering-type, vollständige Vorsequenz, Fähigkeiten, ACL und Sperren, MOVE/ORDERPATCH-Bytes, Position, Antwort, vollständige Depth: 1-Nachsequenz, tatsächliche Version oder Validator und die Verbraucheransicht verknüpfen. Erst dann ist klar, ob zwei Namen dieselbe Sammlung oder zwei Sammlungen verschiedene Ordnungen zeigen.