Zusammenfassung

  • Kann ein Server die Annotationen eines Postfachs nicht nachschlagen, darf er nach RFC 9590 die zugehörige METADATA-Antwort weglassen und LIST dennoch mit OK beenden.
  • Explizites NIL, fehlende Antwort, \NonExistent und ein nur wegen passender Nachfahren ausgegebener Elternname sind vier verschiedene Belegzustände.

Ein Inventurprogramm fragt oberste Postfächer und deren Farbanmerkung ab. Namen und mehrere Farben treffen ein, danach A01 OK List completed. Der Lauf gilt als erfolgreich. Bei einem Namen bleibt das Farbfeld leer.

„Nicht gesetzt“ wäre nur dann belegt, wenn der Server NIL geliefert hätte. Ebenso möglich sind ein nicht ausgeführter Nachschlag, ein bloßer Hierarchieknoten ohne vorhandenes Postfach oder ein Elternname, der allein für einen ausgewählten Nachfahren erschien. Der grüne Abschluss unterscheidet diese Fälle nicht.

Eine Transaktion, viele lokale Ergebnisse

LIST-METADATA registriert METADATA als Rückgabeoption von LIST-EXTENDED. Statt LIST und anschließend je Postfach GETMETADATA zu senden, kann der Client Namen, LIST-Attribute und gewünschte Annotationen gemeinsam anfordern.

Für jedes listbare Postfach, das sowohl zum kanonischen LIST-Muster als auch zu den Auswahloptionen passt, muss der Server LIST und danach eine oder mehrere METADATA-Antworten liefern. RFC 5464 erlaubt, mehrere Eintrag-Wert-Paare zusammenzufassen oder aufzuteilen. Vollständigkeit wird daher pro Postfach und Eintrag geprüft, nicht pro Antwortzeile.

RFC 9590 erlaubt zugleich, die METADATA-Antwort wegzulassen, wenn der Server die Annotationen eines bestimmten Postfachs nicht nachschlagen kann. Das abschließende OK bleibt zulässig. Es bestätigt den Befehlsabschluss, nicht die Füllung aller angeforderten Zellen.

Vier Arten eines leeren Feldes

NIL ist eine ausdrückliche Antwort. Nach RFC 5464 hat der Eintrag keinen Wert. Im Beispiel von RFC 9590 wurde die Farbe von foo nicht gesetzt; METADATA enthält deshalb NIL. Das Paar wurde beantwortet.

Bei einer ausgelassenen Antwort existiert dieses Ergebnis nicht. Unbekannt darf nicht in NIL umgeschrieben werden, denn damit würde der Client eine Serveraussage erfinden.

\NonExistent besagt nach RFC 5258, dass der Name kein bestehendes Postfach bezeichnet, und impliziert \NoSelect. Für Hierarchie- oder Abonnementkontext kann der Name dennoch erscheinen. RFC 9590 zeigt ihn ohne METADATA.

Mit SUBSCRIBED RECURSIVEMATCH kann außerdem ein Elternname nur deshalb zurückkommen, weil ein Nachfahre die Auswahl erfüllt. Erfüllt der Elternname sie nicht selbst, wird für ihn keine METADATA-Antwort erwartet. Das ist Auswahlsemantik, kein Nachschlagfehler.

Der Nenner ist eine fachliche Konstruktion

Nicht alle LIST-Zeilen gehören in den Nenner. Zuerst werden die Namen bestimmt, die Muster und Auswahl erfüllen und tatsächlich Metadatenziele sind; dann werden sie mit den angeforderten Einträgen kombiniert. Konkrete Werte und explizite NILs zählen als beobachtet. Kontextnamen bleiben getrennt, fehlende Antworten für berechtigte Paare sichtbar.

Ein belastbares Protokoll bewahrt Befehlstag, Muster, Auswahl, angeforderte Einträge, LIST-Namen und Attribute, erwartete Paare, Werte, NILs, Lücken, Wiederholungen, Sitzungszeitpunkt und Cacheentscheidung. Ohne diese Daten wird „synchronisiert“ zu einer symbolischen Deutung von OK.

RFC 5258 warnt zudem, dass Nachfahren nach LIST, aber vor dem Zugriff gelöscht oder umbenannt werden können. Die Antwort ist zeitgebunden. Auch RFC 9051 macht aus Befehlsende keinen Beweis für Anzeige oder menschliche Wahrnehmung.

IANA registriert Wörter, keine Betriebsergebnisse

Die IANA-Register enthalten LIST-METADATA und die METADATA-Option. Damit ist ein interoperables Vokabular belegt, nicht Verbreitung, Produktkonformität oder eine beobachtete Fehlerquote.

Running-Code Primacy begrenzt die ausführbare Aussage auf gesendete Bytes und korrekt zusammengesetzte Paare. Die minimale gemeinsame Spezifikation gibt ihnen Bedeutung. Wiederholungsbudget, Cachealter, Darstellung unbekannter Werte und Akzeptanzschwelle bleiben lokal. Sie gehören nicht heimlich in die Bedeutung von OK.

Quellen