Zusammenfassung

  • Auswahloptionen bestimmen die Mitgliedschaft in der Ergebnismenge; Rückgabeoptionen ergänzen nur Informationen zu bereits ausgewählten Namen. Ohne die genaue Anfrage fehlt jeder Zeile ihre Begründung.
  • RECURSIVEMATCH kann einen Elternnamen wegen eines Nachfahren zurückgeben, obwohl der Elternname SUBSCRIBED nicht erfüllt oder \NonExistent trägt; CHILDINFO bewahrt diese zeitgebundene Ursache.

Zwei Arten von Macht in einem einzigen Befehl

Eine Ordneransicht wirkt wie ein Register. Einrückung vermittelt Zugehörigkeit, ein Aufklappsymbol verspricht Kinder, und jede sichtbare Zeile sieht wie ein vorhandenes, auswählbares Objekt aus. Die Oberfläche verschweigt jedoch, welche Frage dieses Bild erzeugt hat.

LIST-EXTENDED trennt innerhalb der Anfrage zwei Befugnisse. Reference name und Muster bestimmen die Vergleichsfläche. Selection options verändern, welche Namen Mitglieder der Antwort werden. Return options bestimmen, welche zusätzlichen Aussagen über diese Mitglieder erscheinen. Authentifizierter Principal, Capability-Generation und Verarbeitungszeit grenzen die Beobachtung weiter ein.

Derselbe Serverzustand kann deshalb mehrere zutreffende Bäume erzeugen. Eine Anfrage wählt abonnierte Namen. Eine andere wählt lokale Postfächer und annotiert danach ihren Abonnementstatus. REMOTE erweitert die Population. RECURSIVEMATCH kann einen nicht passenden Elternnamen als Wegweiser zu einem passenden Nachfahren liefern.

Wer nur die Antwortzeilen speichert, verliert diese beiden Befugnisse. Ein belastbarer Beleg enthält Server und Sitzung, beworbene Capabilities, Principal, reference name, rohe und kanonische Muster, Auswahl- und Rückgabeoptionen, command tag, sämtliche ungetaggten Antworten und den Zeitpunkt. Erst dieser Beleg erklärt, warum die sichtbare Zeile Autorität für genau diese Aussage hatte.

SUBSCRIBED ist entweder Eintrittsgrund oder Zusatzinformation

Eine selection option legt Zulassungsbedingungen fest. Normalerweise muss ein Name mindestens einem kanonischen LIST-Muster entsprechen und alle Auswahlkriterien erfüllen. RECURSIVEMATCH besitzt eine ausdrücklich definierte Sonderregel für übergeordnete Namen; daraus entsteht keine allgemeine Lockerung.

Eine return option darf dagegen keinen weiteren Namen in die Antwort aufnehmen. Sie beschreibt Namen, die bereits ausgewählt wurden. Werden Annotation und Filter vertauscht, bleibt die Darstellung vielleicht plausibel, doch die Ergebnismenge beantwortet eine andere Frage.

SUBSCRIBED macht diese Grenze sichtbar. Als selection option wählt es abonnierte Namen statt existierender Postfächer. Das Ergebnis kann existierende Postfächer auslassen und einen abonnierten Namen enthalten, dessen Postfach gelöscht wurde. Als return option hängt SUBSCRIBED nur den korrekten Status an Namen, welche die zugrunde liegende LIST-Auswahl schon geliefert hat.

Die SUBSCRIBED-Auswahl impliziert die gleichnamige Rückgabeoption; deshalb erhalten ausgewählte Zeilen \Subscribed. Dennoch muss der Beleg festhalten, ob das Abonnement die Zeile zugelassen hat oder lediglich an einer anderweitig ausgewählten Zeile beobachtet wurde. Für Migration und Bereinigung sind das verschiedene Tatsachen.

Auch LIST (SUBSCRIBED) und LSUB sind nicht austauschbar. Die erweiterte Form verlangt vollständige, genaue Attribute in ihrer gewöhnlichen Bedeutung. LSUB trägt historisch besondere Semantik. Eine gemeinsame Normalform „abonnierte Ordner“ beseitigt ausgerechnet die Unterscheidung, die RFC 5258 schaffen sollte.

Der Elternname kann den Filter verfehlt haben

Angenommen, Foo/Baz ist abonniert, Foo dagegen nicht. Ein auf die erste Ebene begrenztes Muster erreicht das Kind nicht; das SUBSCRIBED-Kriterium verwirft den Elternnamen. Ohne Rekursionskontext bleibt die Antwort leer, obwohl tiefer ein relevantes Abonnement liegt.

Mit RECURSIVEMATCH kann der Server Foo samt CHILDINFO (SUBSCRIBED) liefern. Der Elternname muss weiterhin zum kanonischen LIST-Muster passen. Der verursachende Nachfahre muss dieses Muster nicht erfüllen. Die Zeile sagt: Mindestens ein Nachfahre erfüllt das Kriterium, und dieser Elternname macht seinen Ort verständlich.

Sie sagt nicht, dass Foo selbst abonniert ist. Wird CHILDINFO entfernt und nur der Name gecacht, verwandelt sich Kontext in Direktstatus. Erhält jede gerenderte Zeile automatisch SELECT-, Verschiebe- oder Löschaktionen, bekommt ein erklärender Knoten Rechte, die der Server nie nachgewiesen hat.

Die Gültigkeitsregel unterstreicht den Zweck. RECURSIVEMATCH darf weder allein noch nur zusammen mit REMOTE auftreten; der Server muss dann BAD zurückgeben. Es braucht ein weiteres Kriterium, dessen Erfüllung durch einen Nachfahren erklärt werden kann. Es ist kein universeller Schalter für eine vollständige rekursive Aufzählung.

Der Namenspfad kann eine Lücke enthalten

Eine IMAP-Hierarchie verlangt nicht, dass jedes textuelle Präfix als Postfach existiert. Customers/ABC kann vorhanden sein, obwohl es kein Postfach Customers gibt. Für die Darstellung des Pfads bleibt der Elternname dennoch nützlich.

RFC 5258 kann ihn dann mit \NonExistent und CHILDINFO (SUBSCRIBED) zurückgeben. Beide Attribute gelten zugleich. Der Name bezeichnet kein vorhandenes Postfach und impliziert \NoSelect; er erschien, weil ein Nachfahre das Auswahlkriterium erfüllte.

Ebenso können \Subscribed und \NonExistent gemeinsam wahr sein. Das Abonnement ist Zustand eines Namens, Existenz ist Zustand des Postfachobjekts. Nach einer Löschung kann der Abonnementeintrag bestehen bleiben. Wer Abonnement als Existenzbeweis nutzt, verdeckt den Rückstand, den ein Abgleich gerade finden muss.

RFC 2342 behandelt eine benachbarte, aber andere Grenze. NAMESPACE beschreibt die Organisation persönlicher, anderer und geteilter Namen, ohne Existenz oder Zugriff zu belegen. RFC 5258 fragt nach der Ursache innerhalb einer ausgeführten Entdeckungsabfrage: Selbst dort kann eine Zeile wegen eines Nachfahren und nicht wegen ihres eigenen Zustands erscheinen. Namensgrammatik und Auswahlursache brauchen getrennte Nachweise.

CHILDINFO ist eine Begründung, kein Zeiger auf das Kind

CHILDINFO nennt die Auswahlkriterien, die den nicht passenden Vorfahren in die Antwort brachten, und bestätigt mindestens einen passenden Nachfahren. Es nennt den Nachfahren nicht und hält weder seinen Namen noch seine Erreichbarkeit fest.

Zwischen LIST-Antwort und Folgezugriff kann eine andere Sitzung das Kind löschen oder umbenennen. Eine ACL kann sich ändern. Ein korrekter Client muss damit umgehen, dass die nächste Suche keinen passenden Nachfahren mehr findet. CHILDINFO ist eine zeitgebundene Beobachtung, kein dauerhafter Fremdschlüssel.

Bei mehreren gepipelten LIST-Kommandos hilft die Ursache außerdem bei der Zuordnung ungetaggter Antworten. CHILDINFO-Kriterien, Anfragedaten und Empfangsreihenfolge bilden gemeinsam die Abhängigkeitsinformation. Der abschließende Tag allein erklärt nicht jede dazwischen eingetroffene Zeile.

Der Server sollte redundantes CHILDINFO unterdrücken, wenn er auch ein passendes Kind zurückgibt. Aus diesem SHOULD folgt keine sichere Abwesenheitsregel. Ein Client muss Redundanz ohne Doppelzählung akzeptieren und darf fehlendes CHILDINFO nicht als Beweis fehlender Nachfahren deuten, wenn die Antwort es nicht enthalten musste.

CHILDINFO ist schließlich nicht \HasChildren. Ersteres erklärt den Auswahlgrund für einen Vorfahren. Letzteres beschreibt zugängliche Kinder für die Navigation. Kausale Provenienz und Strukturhinweis dürfen nicht zu einem Feld verschmelzen.

Ein Aufklappsymbol ist principal- und zeitgebunden

Die return option CHILDREN fordert \HasChildren oder \HasNoChildren an. Damit kann ein Client eine eingeklappte Hierarchie zeichnen, ohne vorher jeden Zweig zu laden. Die Optimierung überführt eine Serverbeobachtung in ein vertrautes UI-Signal.

Der Server sollte \HasChildren nicht melden, wenn zwar Kinder existieren, der aktuelle Nutzer aber keines erreichen kann; die effiziente Ermittlung ist nicht immer möglich. Ein bei Verarbeitung korrektes Attribut kann vor dem nächsten Klick veralten, wenn ein Kind gelöscht oder der Zugriff geändert wird.

\HasNoChildren bedeutet, dass für den authentifizierten Principal keine zugänglichen Kindpostfächer vorhanden sind. Es behauptet keine globale Nichtexistenz. Es unterscheidet sich von \NoInferiors, das besagt, dass Kinder nicht existieren und künftig nicht angelegt werden können. Beide als permanentes Blattmerkmal zu speichern, verwechselt Sichtbarkeit mit struktureller Unmöglichkeit.

Ein sicherer Cache-Schlüssel umfasst Server, Konto oder Principal, Namespace-Generation, Postfachname, Generation der Zugriffsrichtlinie und Beobachtungszeit. Das Aufklappen bleibt eine erneuerbare Entdeckungsaktion, keine Erlaubnis, gecachte Nachfahren aufgrund einer alten Beobachtung zu löschen.

Reichere Projektionen bleiben Projektionen

REMOTE ist ungewöhnlich, weil es die Auswahlpopulation auf entfernte und lokale Postfächer erweitert und keine entsprechende return option besitzt. Ein gelieferter Remote-Name beweist dennoch weder Erreichbarkeit noch erfolgreichen SELECT noch Nachrichtenzugriff.

LIST-STATUS kann Statusdaten, SPECIAL-USE Rollen und NOTIFY oder CONTEXT Aktualisierungsmechanismen hinzufügen. RFC 4314 hält ACL-Rechte von der bloßen Sichtbarkeit eines Namens getrennt. Mehr Information und Aktualität machen den Baum brauchbarer, aber nicht unabhängig von Anfrage, Principal und Generation.

Die IANA-Register stabilisieren das Vokabular der Capabilities und Mailbox-Name-Attribute. Ein eingetragener Token besitzt eine normative Referenz; daraus folgen weder Werbung noch korrekte Berechnung in einer konkreten Installation. RFC 9051 führt modernes IMAP fort, ohne den konkreten Nachweis zu ersetzen: Welches Kommando lief für welche Identität, und warum erschien jede Zeile?

Lu Hengs Disziplin der Realitätsschichten liefert die Führungsregel. Der Elternname ist als Element einer Antwort real. Der Nachfahre ist als gemeldete Ursache zu einem Zeitpunkt real. Postfach, Abonnement, Recht, Synchronisation und Bildschirmknoten sind getrennte Realitäten. Eine nützliche Abstraktion bleibt nur dann vertrauenswürdig, wenn ihre Verknüpfungen rückwärts bis zu diesen Beobachtungen verfolgt werden können.

Quellen