Alle guten drafts sind 3, also hier noch ein Vorschlag: Das Amiga Filesystem verwendet doch intern
messages. Man wäre also recht schnell bei einem network filesystem, wenn man für das
bestehende Amiga (oder AROS, mit einigen Änderungen) Filesystem Interface ein Wire Format
spezifiziert. Nichts gegen CIFS oder NFS, aber ich muss doch kein AROS filesystem in NFS
einpacken, wenn ich auf der andere Seite wohlmöglich wieder das AROS filesystem interface
benutzen möchte. Das 'R' in AROS steht ja auch für Reseach, daher könnte man hier durchaus
ein wenig forschen, auch wenn man vermutlich ähnliche Ideen wie in NFS und CIFS schon
existieren herleiten wird.

Bernhard Fastenrath wrote:

Ich habe irgendwann um 1998 mal ein kommerzielles Produkt gesehen, dass war so eine Art Wiki, nur
komplizierter und mit stabilen, bidirektionalen Links. Man könnte auch ein Standard für stabile
bidirektionale Links zwischen Wiki Seitenfragmenten spezifizieren. Dann könnte also in der Wikipedia
jemand die Information hinterlegen, dass sein Wiki auf eine Überschrift einer Seite verlinkt und Wikipedia
könnte einem Editor mitteilen, dass eine Überschrift nicht gelöscht werden sollte, oder ihre Aufgabe
sinngemäß einer anderen Überschrift übertragen werden sollte, damit der "incoming Link" nicht
ins Leere geht. Das könnte man auch als IETF draft einreichen. Das hätte insbesondere den Vorteil,
dass verschiedene Wikis und Nicht-Wikis ein einheitliches Protokoll für diesen Zweck hätten.

Bernhard Fastenrath wrote:

Ich suche Koautoren für einen IETF draft. Das Portnummern Mapping über /etc/services ist mir zu simpel.
Ich würde gerne etwas wie ONC RPC portmap bzw. der Java Registry spezifizieren, aber allgemeiner
und nicht nur für RPC oder RMI. Natürlich sollte das Ergebnis ein offener Standard sein mit einer GPL
Referenzimplementierung.

Zu addressieren wären evtl.: Zugriffsrechte, SSL/TLS, tunneling/forwarding, VPN, load balancing,
filtering, namespaces, versioning, message queues (z.B. siehe OS/2 ?), RPC, RMI, failover und monitoring.

Zugriffsrechte könnten beispielsweise einen Dienst sperren bis dieser über die allgemeine Zugriffskontrolle
für den Anrufer freigeschaltet wird. Also auch eine SSH würde nicht antworten, als wäre sie hinter einer
Firewall, bis man den Dienst freischaltet. Okay, man könnte dann gleich ein VPN verwenden, aber vielleicht
gibt es ja auch Nachfrage für eine weniger aufwendige, wenn auch weniger sichere Lösung.