Zusammenfassung

  • Die NFSv4-Arbeitsgruppe setzt das vorgeschlagene optionale Attribut ACL_Choice in der Fassung -06 vom 29. September auf Nummer 89 statt 87. In zwei gesonderten Entwürfen stehen 87 und 88 für nicht zwischenspeicherbare Dateidaten beziehungsweise Verzeichniseintrags-Metadaten.
  • Vier vorgeschlagene ACL-Größenfehler wandern von 20000–20003 auf 10095–10098. Eine neue Einschränkung knüpft ihre Rückgabe an AclChoice-Unterstützung sowohl des Servers als auch des betroffenen Dateisystems. Über diesen Abschnitt besteht noch kein abschließender Konsens.

Bei einem Protokolltest kann der erste Erfolg täuschen: Ein neuer Decoder erkennt Feld 89 und zeigt einen Namen an. Das belegt aber nur seine eigene Zuordnungstabelle. Der Schritt zwischen zwei Fassungen von ACLs within the NFSv4 Protocols zeigt, warum Versions- und Fähigkeitsnachweise dazugehören. Der Entwurf -05 vom 14. September verwendete 87 für ACL_Choice; der Entwurf -06 vom 29. September nennt 89, sowohl in der Attributübersicht als auch in der XDR-Konstante. Laut Änderungsprotokoll soll die Verschiebung Platz für die zwei Uncacheable-Vorhaben schaffen. Dort trägt uncacheable_file_data die 87, uncacheable_dirent_metadata die 88.

Das sind nicht drei Varianten derselben Funktion. ACL_Choice soll als optionales Attribut im geplanten NFSv4.1-Bis-Kontext Auskunft über ACL-Verhalten geben. Die beiden Nachbarentwürfe betreffen das Caching von Dateidaten und Verzeichniseintrags-Metadaten. Eine kollisionsfreie Tabelle erleichtert gemeinsame Weiterentwicklung. Sie beweist weder eine tatsächlich aufgetretene Kollision bei einem Betreiber noch eine bereits abgeschlossene Zuteilung in einem RFC. Ob ein Anbieter einen früheren Wert jemals ausgeliefert hat, lässt sich aus den Dokumenten nicht ableiten.

Bei den Fehlern wird die Grenze zwischen Nummer und Funktion noch deutlicher. Die vier neuen Namen unterscheiden Fälle, in denen eine ACL wegen Größe nicht gespeichert oder nicht zurückgegeben werden kann: NFS4ERR_ACLST_POORFIT, NFS4ERR_ACLST_NOFIT, NFS4ERR_ACLST_TOOBIG und NFS4ERR_ACLFT_TOOBIG. Ihre vorgeschlagenen Werte wechseln von 20000 bis 20003 auf 10095 bis 10098. Zusätzlich darf ein Server nach neuer Entwurfsformulierung diese Fehler nicht senden, wenn er AclChoice nicht unterstützt. Dasselbe gilt, wenn gerade das angesprochene Dateisystem die Funktion nicht unterstützt. Ein Server kann also nicht als einheitlicher Fähigkeitsblock betrachtet werden.

Man stelle sich zwei Exporte desselben Servers vor. Auf dem ersten stellt das zugrunde liegende Dateisystem die neue ACL-Information bereit, auf dem zweiten nicht. Ein Client mit aktueller Fehlernamensliste kann daraus keine gemeinsame Semantik für beide Exporte ableiten. Er muss die Anfrage, den Ziel-Export und die tatsächlich verfügbare Eigenschaft zusammen betrachten. Das ist ein mögliches Testszenario, kein Bericht über einen entdeckten Produktfehler.

Der IETF-Datatracker führt -06 weiterhin als aktiven Arbeitsgruppen-Internet-Draft mit dem Status I-D Exists. RFC 7530 und RFC 8881 würden laut Titelblatt erst im Fall einer Genehmigung aktualisiert. Im Text ist von Arbeit auf einen künftigen Working Group Last Call hin die Rede; der Fehlerabschnitt trägt ausdrücklich einen Konsensvorbehalt. Eine Formulierung mit MUST NOT im Entwurf ist deshalb noch keine heute geltende neue RFC-Pflicht.

Quellen