<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><br>
      Ich habe irgendwann um 1998 mal ein kommerzielles Produkt gesehen,
      dass war so eine Art Wiki, nur<br>
      komplizierter und mit stabilen, bidirektionalen Links. Man könnte
      auch ein Standard für stabile<br>
      bidirektionale Links zwischen Wiki Seitenfragmenten spezifizieren.
      Dann könnte also in der Wikipedia<br>
      jemand die Information hinterlegen, dass sein Wiki auf eine
      Überschrift einer Seite verlinkt und Wikipedia<br>
      könnte einem Editor mitteilen, dass eine Überschrift nicht
      gelöscht werden sollte, oder ihre Aufgabe<br>
      sinngemäß einer anderen Überschrift übertragen werden sollte,
      damit der "incoming Link" nicht<br>
      ins Leere geht. Das könnte man auch als IETF draft einreichen. Das
      hätte insbesondere den Vorteil,<br>
      dass verschiedene Wikis und Nicht-Wikis ein einheitliches
      Protokoll für diesen Zweck hätten.<br>
      <br>
      Bernhard Fastenrath wrote:<br>
    </div>
    <blockquote cite="mid:527CD9FE.8050505@arcor.de" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <br>
      Ich suche Koautoren für einen IETF draft. Das Portnummern Mapping
      über /etc/services ist mir zu simpel.<br>
      Ich würde gerne etwas wie ONC RPC <a moz-do-not-send="true"
        href="http://en.wikipedia.org/wiki/Portmap">portmap</a> bzw. der
      Java Registry spezifizieren, aber allgemeiner<br>
      und nicht nur für RPC oder RMI. Natürlich sollte das Ergebnis ein
      offener Standard sein mit einer GPL<br>
      Referenzimplementierung.<br>
      <br>
      Zu addressieren wären evtl.: Zugriffsrechte, SSL/TLS,
      tunneling/forwarding, VPN, load balancing,<br>
      filtering, namespaces, versioning, message queues (z.B. siehe OS/2
      ?), RPC, RMI, failover und monitoring.<br>
      <br>
      Zugriffsrechte könnten beispielsweise einen Dienst sperren bis
      dieser über die allgemeine Zugriffskontrolle<br>
      für den Anrufer freigeschaltet wird. Also auch eine SSH würde
      nicht antworten, als wäre sie hinter einer<br>
      Firewall, bis man den Dienst freischaltet. Okay, man könnte dann
      gleich ein VPN verwenden, aber vielleicht<br>
      gibt es ja auch Nachfrage für eine weniger aufwendige, wenn auch
      weniger sichere Lösung.<br>
    </blockquote>
    <br>
  </body>
</html>