Koautoren für einen IETF draft gesucht

[Bernhard Fastenrath]

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 
>> <http://en.wikipedia.org/wiki/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.
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20131108/8a8d4771/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : Bernhard_Fastenrath_2.vcf
Dateityp    : text/x-vcard
Dateigröße  : 342 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20131108/8a8d4771/attachment.vcf>